Não basta que a organização publique uma política de uso responsável da inteligência artificial e presuma que o comportamento a seguirá. Os desenvolvedores trabalham sob pressão para entregar resultados e enfrentam problemas pouco claros; por isso, podem recorrer a ferramentas não autorizadas quando o canal oficial parece lento ou desconectado dos detalhes do trabalho de engenharia. É nesse contexto que o artigo publicado no Stack Overflow Blog apresenta uma ideia central: limitar a “inteligência artificial oculta” começa pelo design do fluxo de trabalho, não pela adição de outro documento ao portal de aprendizagem.
O material baseia-se nos resultados da Stack Overflow sobre adoção da inteligência artificial e confiança dos desenvolvedores; 84% dos participantes disseram que usam ferramentas de inteligência artificial ou planejam usá-las, enquanto o número de desenvolvedores que não confiam na precisão dessas ferramentas supera o número dos que confiam nelas. Resultados que parecem quase corretos, mas exigem correção adicional, estavam entre as principais fontes de frustração.
O uso não autorizado é um sinal de falha no fluxo de trabalho
O artigo propõe que a administração não trate todo uso não autorizado como uma violação de conformidade completa. Quando um engenheiro copia material sensível para um modelo público ou instala um assistente de programação não autorizado, isso pode indicar que o caminho aprovado não fornece os dados, o contexto, as integrações ou as permissões necessários para concluir a tarefa.
A resposta prática começa com perguntas diagnósticas: quais tarefas levam os desenvolvedores a ferramentas externas? Que atrito dificulta a alternativa aprovada? É possível oferecer experimentação por meio de plataformas aprovadas e portas de monitoramento que registrem o uso, em vez de tentar impedi-lo com uma proibição geral? Sob essa perspectiva, o uso informal torna-se uma evidência que ajuda a organização a melhorar o sistema, não um motivo automático para obrigar os funcionários a ocultar suas experiências.
Transformar a política em uma interface de engenharia
Uma boa política define o propósito, mas uma boa operação o traduz em decisões que o desenvolvedor consegue tomar durante o trabalho diário. O artigo aponta as funções da estrutura do NIST para o gerenciamento de riscos de inteligência artificial: governança, identificação, medição e gerenciamento. Na prática, as regras devem esclarecer como classificar o caso de uso, quais modelos e fontes de dados são permitidos, como testar os resultados, qual parte é responsável pela aprovação e quais evidências devem ser mantidas no registro de desenvolvimento.
Entre as perguntas que a política deve responder diretamente estão: quais dados podem ser inseridos em cada ferramenta? A quais repositórios ou sistemas a ferramenta pode ter acesso? Qual nível de revisão é exigido para o código gerado? Quando é necessária a intervenção de um responsável humano? Como o desenvolvedor deve comunicar resultados prejudiciais, inseguros ou não confiáveis? E quando a experimentação se transforma em um sistema de produção? O artigo afirma que segurança e privacidade estão entre os principais motivos pelos quais os desenvolvedores rejeitam tecnologias, o que torna regras claras um fator de apoio à adoção quando reduzem a ambiguidade.
Coloque os controles onde o trabalho acontece
Uma política armazenada em um portal de treinamento dificilmente compete com um assistente integrado ao ambiente de desenvolvimento integrado. Por isso, o artigo propõe colocar os controles nos repositórios, nas solicitações de mesclagem, nos pipelines de compilação, nos sistemas de acesso e nos fluxos de trabalho de implantação. Exemplos incluem armazenar as configurações dos modelos aprovados em um sistema de controle de versões, restringir o acesso por função, verificar solicitações e resultados em busca de segredos, manter registros nos casos de uso de maior risco e exigir testes antes da mesclagem de alterações geradas.
A frase “revise os resultados da inteligência artificial” também deve ser transformada em etapas reproduzíveis, como testes funcionais, verificação da adequação ao contexto, revisão de dependências e revisão coletiva quando necessário. Um único nível de aprovação não é adequado para todos os usos; uma ferramenta que explica código apresenta riscos diferentes dos de um agente com permissão de escrita em sistemas de produção. O artigo menciona riscos da lista da OWASP para aplicações de inteligência artificial generativa, incluindo injeção de prompts, exposição de informações sensíveis, fragilidade da cadeia de suprimentos, tratamento inadequado dos resultados e permissões excessivas.
Responsabilidade, treinamento e medição
Deve ser designado um responsável humano claro para cada caso de uso, alguém que compreenda o resultado desejado e tenha autoridade para interromper ou modificar o processo. De acordo com a divisão proposta, os líderes de produto assumem a decisão comercial; os líderes de engenharia, a qualidade da execução; os especialistas em segurança e privacidade definem os controles adequados; os desenvolvedores são responsáveis pelo código que entregam; os revisores, pela decisão de aprová-lo; e os operadores, pelo monitoramento e pela resposta a incidentes.
O artigo também defende um treinamento relacionado às decisões reais dos desenvolvedores, e não uma sessão geral de conscientização. Isso inclui as ferramentas aprovadas, os dados permitidos, os padrões de falha, os requisitos de revisão, o caminho de escalonamento e exemplos do ambiente da organização. O treinamento deve produzir elementos utilizáveis dentro do fluxo de trabalho, como instruções de repositório, listas de verificação, conjuntos de testes, padrões de prompts aprovados e exemplos documentados; o certificado comprova a presença, mas são esses elementos que influenciam o comportamento.
Quanto à medição do sucesso, ela não deve se limitar ao número de licenças, prompts ou usuários ativos. O artigo propõe comparar o fluxo de trabalho antes e depois da introdução da ferramenta, usando indicadores como tempo de ciclo, defeitos que chegam à produção, operações de reversão, resultados de verificações de segurança, carga de revisão, qualidade da documentação, incidentes, satisfação dos desenvolvedores e tempo gasto na correção dos resultados. Esse ponto merece atenção especial porque os resultados do DORA de 2024 associaram uma adoção maior à melhoria da qualidade da documentação e do código e à maior velocidade de revisão, mas também identificaram possíveis efeitos negativos no desempenho da entrega de software. A pesquisa da Stack Overflow também indicou possíveis ganhos individuais com agentes, sem ganhos equivalentes na colaboração coletiva.
A leitura editorial da certi.news
A mudança efetiva proposta pelo material não está na redação de uma nova política, mas na transferência da responsabilidade do nível dos documentos para o nível das ferramentas e dos processos. O caminho seguro torna-se utilizável quando oferece ferramentas aprovadas, contexto útil, limites claros, escalonamento rápido e controles proporcionais à sensibilidade dos dados, ao grau de autonomia e à possibilidade de reverter o impacto.
Isso não é uma receita para eliminar o julgamento humano, mas uma tentativa de torná-lo uma parte visível do ciclo de desenvolvimento. A eficácia das propostas continua ligada à capacidade de cada organização de definir os casos de uso e medir seus resultados reais; além disso, os números citados no artigo resumem resultados de diversos estudos e pesquisas e, por si só, não provam que todo ambiente de desenvolvimento alcançará o mesmo resultado.