Há apenas alguns anos, a resposta à pergunta "quem escreveu este código?" era relativamente simples. Era possível apontar para o programador, a equipa ou a software house responsável por um módulo específico.
Hoje, a situação é completamente diferente.
Uma parte do código pode ser escrita manualmente. Outra pode ser gerada pelo Copilot. Um terceiro fragmento pode ser criado por um agente de programação. Outro será obtido de uma biblioteca open source. Mais um será uma dependência de um pacote externo. A isso somam-se APIs, serviços cloud, componentes prontos, frameworks e ferramentas fornecidas por outras empresas.
O sistema funciona. Mas será que você realmente sabe, do que ele foi construído?
Código gerado por IA não surge no vazio
O avanço das ferramentas de IA para programação está a mudar não só a forma de escrever software. Está também a mudar a estrutura de responsabilidade pelo código.
Hoje, um programador pode descrever uma tarefa a um agente e depois receber uma função pronta, um módulo, testes, configuração ou até uma proposta de alterações arquitetónicas. É um enorme aumento de produtividade.
O problema começa quando tratamos o código gerado como "código do nada".
A IA não cria código isoladamente do ecossistema de desenvolvimento. Os modelos são treinados com enormes conjuntos de dados, e o fragmento gerado pode ser semelhante a soluções existentes, padrões ou código publicamente disponível. É precisamente por isso que a questão da origem do código, das licenças e da responsabilidade se torna cada vez mais importante.
Isso não significa automaticamente que cada fragmento de código gerado por IA viole a licença de alguém. Significa, porém, que uma organização que usa IA no processo de desenvolvimento de software deve tratar a origem e a verificação do código como parte do processo de engenharia, e não como uma curiosidade jurídica.
Isto já não é apenas teoria
Em 16 de setembro de 2026, o Tribunal de Apelação do 9.º Circuito decidiu parte do caso Doe v. GitHub, no qual programadores acusavam o GitHub, a Microsoft e entidades da OpenAI, entre outras coisas, de utilizarem código publicamente disponível do GitHub na criação e no treino de ferramentas como o Copilot e o Codex.
Uma das reivindicações dizia respeito ao DMCA e às informações de direitos de autor. O tribunal manteve a rejeição dessa acusação específica. Ao mesmo tempo, o caso também abrange outras questões relacionadas com direitos de autor e licenças open source.
Isto é importante não porque uma única decisão dê uma resposta simples à pergunta "pode-se usar código de IA".
Não dá.
O mais importante é que a disputa mostra um problema mais amplo: no mundo da IA, a fronteira entre código escrito por humanos, código gerado por um modelo e código proveniente de um ecossistema de software existente torna-se cada vez mais difícil de rastrear.
E, para empresas que desenvolvem software, isso significa a necessidade de gerir melhor esse processo.
Software supply chain, ou o seu sistema tem muito mais "autores"
Na segurança de software, existe há anos o conceito de software supply chain - a cadeia de fornecimento de software.
São todos os componentes, ferramentas, bibliotecas, dependências e processos que participam na criação do produto final.
O NIST aponta nesse contexto, entre outros aspetos, para a necessidade de gerir a origem dos componentes, controlar dependências open source, monitorizar vulnerabilidades e usar SBOM, ou seja, Software Bill of Materials.
Em termos simples, um SBOM pode ser comparado a uma lista de ingredientes do produto.
Não diz apenas "temos uma aplicação". Mostra quais componentes estão dentro dela.
Por exemplo:
- framework da aplicação,
- bibliotecas externas,
- versões dos diferentes pacotes,
- componentes open source,
- dependências indiretas,
- elementos fornecidos por terceiros.
Assim, quando surge uma vulnerabilidade numa biblioteca específica, é possível verificar mais rapidamente quais sistemas a utilizam.
O NIST chama também a atenção para a proveniência, ou seja, a possibilidade de rastrear a origem dos elementos de software.
E é precisamente aqui que a IA acrescenta um novo nível de complexidade.
Porque ao cadeia existente soma-se mais uma forma de o código ser criado.
Imagine um sistema empresarial típico
40% do código foi escrito pela equipa.
20% foi criado com apoio de IA.
Outros fragmentos foram gerados por um agente.
Algumas bibliotecas vêm de open source.
Parte das dependências foi adicionada pelo framework.
O sistema usa a API de um fornecedor externo.
Um componente vem de um pacote que ninguém atualizou há dois anos.
E a documentação das dependências?
Está algures no repositório.
Ou não existe.
O sistema funciona...
E é precisamente por isso que o problema é invisível. Até algo acontecer.
E então surge uma vulnerabilidade
Suponha que é detetada uma falha grave de segurança numa das bibliotecas.
A pergunta é: você sabe se o seu sistema a utiliza?
Se tiver um registo organizado de dependências, a resposta pode ser uma questão de minutos.
Se não tiver, começa a procura manual pelos repositórios, o contacto com programadores, a verificação de ambientes, versões de pacotes e dependências indiretas.
E agora vamos adicionar a isso código gerado por IA.
Sabe-se qual fragmento foi criado com que ferramenta?
Foi feita code review?
O código foi coberto por testes?
As dependências foram verificadas?
Alguém validou a licença do componente?
É possível reconstruir o processo que levou à criação de um fragmento específico?
Estas já não são perguntas apenas para o programador.
São perguntas sobre a gestão do risco tecnológico da empresa.
O maior problema não é a IA. É a falta de processo
Seria fácil transformar este artigo num aviso contra a inteligência artificial.
No entanto, essa seria uma conclusão demasiado simples.
A IA pode melhorar fortemente a produtividade da equipa de desenvolvimento.
O problema surge quando a empresa aumenta o ritmo de produção de código, mas não aumenta ao mesmo tempo o controlo sobre esse código.
É um pouco como se uma fábrica passasse subitamente a produzir dez vezes mais peças, mas sem aumentar o controlo de qualidade, o registo de materiais nem a supervisão de fornecedores.
Numa software house, os equivalentes desse sistema de controlo incluem, entre outros:
- code review
- testes automáticos
- análise de dependências
- SBOM
- monitorização de vulnerabilidades
- controlo de licenças open source
- CI/CD com controlos de segurança
- gestão de repositórios
- documentação da arquitetura
- rastreio da proveniência dos componentes
- regras claras para o uso de IA no desenvolvimento
O NIST também aponta a possibilidade de integrar mecanismos de segurança da cadeia de suprimentos diretamente aos pipelines de CI/CD.
Esta é uma mudança importante de mentalidade.
A segurança não deveria ser uma verificação realizada apenas antes do deploy.
Deveria fazer parte do processo de criação de software.
"Quem escreveu este código?" deixa de ser a pergunta certa
No mundo do desenvolvimento tradicional, era possível perguntar pelo autor.
No mundo do desenvolvimento assistido por IA, perguntas muito mais importantes passam a ser:
- De onde vem este componente?
- Qual é a sua licença?
- Quem o verificou?
- Qual versão estamos usando?
- Quais dependências ele tem?
- Ele ainda é mantido?
- Conhecemos suas vulnerabilidades?
- Podemos reconstruir o histórico de mudanças?
- Sabemos onde a IA participou da sua criação?
E, acima de tudo:
- A empresa consegue provar que tem controle sobre tudo isso?
Porque o cliente não compra "código feito por IA". Ele compra um sistema funcional. E a responsabilidade por esse sistema continua sendo da organização que o entrega e o mantém.
O código pode ser automático. A responsabilidade não
Esta é provavelmente uma das mudanças mais importantes que a IA traz para as software houses.
O programador não desaparece. Sua função muda.
Cada vez mais, não se trata apenas de escrever uma determinada quantidade de linhas de código. Trata-se de projetar a solução, controlar os elementos gerados, avaliar riscos, testar, integrar, garantir a segurança e manter todo o sistema.
Da mesma forma, a empresa não pode se limitar a perguntar se seus programadores usam IA.
Ela deve saber como usam, em qual processo, com quais controles e como isso afeta todo o ciclo de vida do software.
Porque daqui a alguns anos a pergunta talvez não seja: "Quem escreveu este sistema?"
mas: "Você consegue reconstruir do que e de que forma ele foi construído?"
Se a resposta for "não totalmente", o problema não é a falta de mais uma ferramenta de IA.
O problema é a falta de controle sobre a cadeia de suprimentos de software.
