Obrigações de Segurança Que Já Se Aplicam a Si Enquanto Programador Independente

Existe uma crença persistente entre programadores independentes de que a regulação de segurança e privacidade é algo que acontece às empresas — que as obrigações começam quando se constitui uma sociedade, se contrata um DPO ou se assina um contrato empresarial. Não é verdade, e há já anos que não é. Se é freelancer ou programador independente e lida com dados de clientes, várias obrigações já se aplicam a si hoje, pessoalmente, na sua dimensão atual. Este artigo percorre quais são essas obrigações, identifica os regulamentos de onde provêm, e termina com a questão prática que realmente importa: o que está, concretamente, exposto nas suas contas neste momento?

Uma coisa que este artigo não fará é dizer-lhe que alguma lei o obriga a comprar uma ferramenta de segurança. Nenhuma o faz. O que a lei exige é que saiba o que está a fazer com os dados que processa e que os proteja de forma adequada — e o ponto de partida honesto para isso é saber que acessos existem nas contas onde reside o trabalho dos seus clientes.

Ao abrigo do RGPD, um freelancer que processa dados de clientes é um subcontratante — com obrigações diretas

Se um cliente na UE (ou um cliente cujos utilizadores estejam na UE) lhe entrega dados pessoais — uma base de dados de utilizadores para migrar, um sistema de produção para depurar, uma exportação para analisar — está quase sempre a atuar como subcontratante ("data processor") ao abrigo do RGPD, e em alguns projetos (quando é você que decide o que recolher e porquê) como responsável pelo tratamento ("controller"). Nenhum dos estatutos exige uma empresa. As definições do RGPD no Artigo 4.º aplicam-se a "uma pessoa singular ou coletiva" — uma pessoa com um portátil qualifica-se.

Esse estatuto acarreta obrigações diretas e pessoais:

• O Artigo 28.º exige que o seu processamento para um cliente seja regido por um contrato — o acordo de tratamento de dados que os seus clientes empresariais continuam a enviar-lhe não é teatro burocrático; é um requisito legal para ambas as partes, e vincula-o a compromissos de segurança específicos.
• O Artigo 32.º exige que implemente "medidas técnicas e organizativas adequadas" para proteger os dados pessoais que processa — adequadas ao risco, o que inclui controlar quem e o quê pode aceder-lhes.
• O Artigo 33.º exige que um subcontratante notifique o responsável pelo tratamento "sem demora injustificada" após ter conhecimento de uma violação de dados pessoais — o que pressupõe que esteja em posição de tomar conhecimento de tal violação.
• O Artigo 82.º confere aos titulares dos dados o direito a indemnização por parte dos subcontratantes por danos causados por um processamento que infrinja o regulamento, e o Artigo 83.º sustenta todo o enquadramento com coimas administrativas que podem atingir, nas infrações mais graves, até vinte milhões de euros ou quatro por cento do volume de negócios anual a nível mundial, consoante o que for mais elevado.

Ninguém está a sugerir que a primeira ação de uma autoridade de supervisão contra um freelancer seja o máximo legal. O ponto é mais simples: as obrigações são reais, aplicam-se diretamente a si, e "sou só uma pessoa" não é uma isenção reconhecida em lado nenhum do texto do regulamento.

O EU AI Act acrescenta obrigações para os responsáveis pela implementação de sistemas de IA

Se o trabalho que faz para os seus clientes já inclui integrar IA em produtos — um assistente na aplicação de um cliente, um agente de IA a automatizar um fluxo de trabalho, um modelo a tomar decisões que afetam pessoas — o EU AI Act é relevante para si. O Regulamento não regula apenas as empresas que treinam modelos; impõe obrigações aos "deployers" (responsáveis pela implementação) — aqueles que utilizam sistemas de IA sob a sua própria autoridade num contexto profissional.

O Artigo 26.º estabelece as obrigações dos deployers para sistemas de IA de risco elevado, incluindo a utilização dos sistemas de acordo com as respetivas instruções, garantir uma supervisão humana adequada, e monitorizar o funcionamento. O Artigo 4.º exige que tanto os fornecedores como os deployers assegurem um nível suficiente de literacia em IA nas pessoas que operam estes sistemas em seu nome. E o Artigo 99.º sustenta o enquadramento com coimas administrativas por incumprimento. Quais as obrigações aplicáveis a um determinado projeto depende do que o sistema faz e da categoria de risco em que se enquadra — mas "eu só o integrei, não o construí" é precisamente a situação para a qual a categoria de deployer foi concebida.

Existe aqui uma ironia prática que observamos constantemente na governação de agentes de IA: os programadores independentes são os maiores adotantes de agentes de codificação por IA e bots de automação — e os menos propensos a ter um inventário do que esses agentes conseguem alcançar. Se um agente de IA consegue fazer push para todos os repositórios que possui, isso é um facto sobre a sua postura de segurança, quer algum regulador alguma vez pergunte sobre isso ou não.

Os seus clientes empresariais já estão regulados — e as suas obrigações refletem-se em si

Mesmo que nunca toque em dados pessoais da UE e nunca implemente um sistema de IA, existe uma terceira fonte de obrigações de segurança que se aplica a quase todos os freelancers que trabalham com empresas de qualquer dimensão: os contratos. Os clientes empresariais operam ao abrigo de relatórios SOC 2, certificações ISO 27001, requisitos de subcontratante do Artigo 28.º do RGPD, e programas de gestão de fornecedores que os seus auditores efetivamente verificam. Esses programas não distinguem entre um fornecedor de 500 pessoas e um fornecedor de uma pessoa só. Um fornecedor é um fornecedor.

É por isso que o questionário de segurança continua a chegar antes do contrato. O seu cliente é obrigado — pelo seu enquadramento, pelo seu auditor, ou pelos seus próprios clientes — a recolher evidências de segurança das pessoas a quem entrega dados. Incluindo você. Os freelancers que conseguem responder com credibilidade ("aqui está o que tem acesso ao meu ambiente de desenvolvimento, aqui está como o controlo, aqui está a evidência") fecham esses negócios mais depressa do que os que improvisam. Escrevemos sobre a versão organizacional desta dinâmica em o que os auditores exigem para a governação de IA em 2026; a versão do lado do fornecedor chega à sua secretária sob a forma de questionário.

O que uma violação custa realmente a um programador independente

Enquadramento de risco, porque é esse o enquadramento honesto: um incidente de segurança num projeto de cliente pode significar responsabilidade financeira direta ao abrigo da cláusula de indemnização do seu contrato, pode significar responsabilidade de subcontratante ao abrigo do Artigo 82.º do RGPD se estiverem envolvidos dados pessoais, e — de forma mais concreta para um freelancer — pode significar o fim da relação com o cliente e da referência que a acompanhava. Para uma consultoria de uma só pessoa, o ativo reputacional é o negócio. Nada disto é exotismo hipotético; é a cadeia normal de consequências quando uma credencial comprometida ou uma integração com permissões excessivas se transforma num incidente com dados de clientes.

Então, o que está realmente exposto na sua conta neste momento?

Aqui está a versão desconfortável e específica da pergunta. O trabalho dos seus clientes reside quase de certeza numa conta pessoal do GitHub. Essa conta acumulou, ao longo de anos de projetos:

• Aplicações GitHub instaladas — bots de implementação, ferramentas de CI, assistentes de IA — cada uma detendo uma permissão que aprovou uma vez e provavelmente nunca mais reviu. Algumas delas têm permissão de escrita ou de administrador sobre tudo o que possui. Algumas pertencem a projetos que terminaram em 2024.
• Chaves de implementação ("deploy keys") — credenciais SSH sem supervisão, colocadas em servidores, algumas com acesso de escrita ao repositório que deveriam apenas ler. Se esse servidor for comprometido, uma deploy key com leitura-escrita é uma via de injeção de código no produto do seu cliente.
• Colaboradores — pessoas que adicionou durante uma colaboração que já terminou, mas que continuam com acesso de escrita, incluindo em repositórios que são públicos.
• Exposição de repositórios — quais dos seus repositórios são públicos, e o que contêm, é em si uma questão de inventário à qual a maioria dos programadores não consegue responder de memória.

Cada um destes pontos é legível por máquina através da própria API do GitHub, o que significa que todos são verificáveis — não confiando na sua memória, mas enumerando o que efetivamente detém acesso hoje. Esse inventário é exatamente o que o conector GitHub da 8200.dev agora produz para contas pessoais, não apenas para organizações: ligue o seu próprio login do GitHub, e a análise lista as aplicações instaladas e as respetivas permissões, as deploy keys e se cada uma é apenas de leitura, os colaboradores por repositório, e as conclusões que resultam desse grafo — o bot esquecido com permissões de administrador, a deploy key com capacidade de escrita, a aplicação obsoleta que ninguém tocou há um ano.

O nível pessoal gratuito executa a análise completa e mostra-lhe as descobertas mais graves; o nível pessoal pago — com um preço equiparável a uma subscrição de completar código, não a software empresarial — desbloqueia a lista completa com monitorização contínua e alertas. E se crescer até se tornar uma agência com uma conta de organização, a mesma análise, as mesmas regras, e o mesmo registo de evidências crescem consigo — essa é a vertente organizacional do produto, e é o mesmo conector.

As obrigações acima aplicam-se a si quer alguma vez execute uma análise, quer não. O que a análise muda é se consegue responder às perguntas que essas obrigações implicam — o que tem acesso, porquê, e o que fez em relação ao acesso que ninguém conseguia justificar. Comece pelo nível gratuito, veja o que se acumulou silenciosamente na sua conta, e decida a partir daí — o preço é público, self-serve, e começa em zero.

*Este artigo constitui informação geral sobre regulamentos que comummente se aplicam a programadores independentes; não constitui aconselhamento jurídico, e a forma como cada regulamento se aplica à sua situação específica depende de factos que um scanner não pode conhecer. Para isso, consulte um advogado.*