Seu funcionário criou um sistema com IA. A empresa é dona dele?
Eu já contei aqui que passo boa parte do dia conversando com o Codex. Uso a ferramenta para organizar ideias, planejar projetos e resolver problemas. E foi justamente por usar tanto que comecei a pensar no que está acontecendo dentro das pequenas empresas.
Imagine uma equipe com cinco ou dez pessoas. Um funcionário se cansa de copiar dados de uma planilha para outra, abre uma ferramenta de IA e cria um aplicativo para gerar propostas. Ele conecta o sistema ao cadastro de clientes, automatiza parte do trabalho e mostra o resultado ao dono.
Funcionou. Ficou rápido. Todo mundo gostou.
Convenhamos: eu também comemoraria.
O problema começa quando alguém pergunta onde está o código. No GitHub pessoal do funcionário. E a senha? Só ele sabe. A hospedagem está no cartão dele, o banco de dados foi criado numa conta gratuita e ninguém mais entende direito como aquela automação funciona.
A bomba costuma estourar na hora do aperto: o funcionário sai, a conta é bloqueada ou uma integração simplesmente para de funcionar.

No papel é uma coisa. Na segunda-feira de manhã é outra.
Se você levar a pergunta do título para um advogado, ele provavelmente começará pelo artigo 4º da Lei do Software. A regra prevê situações em que os direitos pertencem ao empregador, principalmente quando o desenvolvimento tem relação com o contrato, com as atribuições do funcionário ou com a própria natureza do trabalho.
Mas não é automático. A mesma lei trata dos casos em que o programa foi criado sem relação com o emprego e sem usar recursos, equipamentos ou informações da empresa. Contrato, função e circunstâncias importam. Se o sistema for relevante para o negócio, é prudente buscar orientação jurídica. O INPI também explica a importância do registro para ajudar a comprovar autoria e titularidade.
Agora vem a parte incômoda.
A empresa pode ser dona do código no papel. Mas cadê a senha? Quem consegue restaurar o banco de dados? Quem coloca o sistema no ar novamente? Uma decisão jurídica pode reconhecer um direito, mas não recupera o acesso na segunda-feira de manhã.
Na prática, propriedade sem controle vale muito pouco.
Esse problema não nasceu com a IA. Quem nunca encontrou aquela planilha que só uma pessoa sabia atualizar? Já escrevemos sobre como um Manual de Trabalho ajuda a preservar os procedimentos da equipe. A diferença é que agora o funcionário não cria apenas uma planilha. Ele consegue criar um sistema inteiro — e conectá-lo a tudo.
Talvez o código nem seja o mais valioso.
Para testar a aplicação, alguém pode ter enviado listas de clientes, preços, imagens de produtos, contratos ou planilhas financeiras para uma conta pessoal de IA. As políticas variam conforme fornecedor, plano e configuração. O ponto é outro: a empresa não sabe o que foi contratado nem controla as opções escolhidas pelo funcionário.
E tem mais!
Quando a aplicação conversa com outros serviços, importa saber como foi feita a integração por APIs. Uma chave de acesso esquecida no código ou numa conversa pode liberar muito mais informação do que deveria.
Vou ser direto: proibir a equipe de usar IA seria uma péssima ideia. As pessoas continuarão usando, só que escondidas, pelo celular e em contas pessoais. O caminho não é bloquear. É institucionalizar.
Se o aplicativo reduz retrabalho, evita erros ou permite responder mais rápido ao cliente, ótimo. Ele pode diminuir custos e até ajudar a vender mais. Então vamos tratá-lo como um ativo: código em conta da empresa, credenciais sob controle, outra pessoa treinada, documentação mínima e uma cópia recuperável. Aqui valem os mesmos cuidados de um bom serviço de backup empresarial.
Eu gosto da iniciativa de quem vê um problema e resolve. O que me preocupa é a empresa confundir improviso bem-sucedido com patrimônio.
Antes de depender de qualquer aplicação, faça uma pergunta simples: se o criador dela não vier amanhã, a empresa continua trabalhando?
Se a resposta for não, você pode até ser dono do sistema. Só ainda não tem controle sobre ele.

Comentários