Quando o risco da programação com IA é inaceitável?

A assistência de IA para programação torna-se inaceitável quando um erro plausível pode atravessar uma fronteira de produção antes que uma pessoa qualificada prove que a alteração é segura. O risco não depende de o modelo ter escrito dez linhas ou dez mil. Depende de a alteração poder mudar identidades, movimentar dinheiro, reconfigurar infraestrutura compartilhada, influenciar decisões clínicas, reescrever dados persistentes ou enfraquecer um controle de segurança.

Trato essas áreas como zonas vermelhas. A IA ainda pode ajudar dentro delas, mas não pode fornecer o julgamento final, aprovar o próprio trabalho nem transformar um pedido vago em uma alteração de produção. Cada zona vermelha precisa de um responsável humano identificado, evidências adequadas ao tipo de falha e uma barreira de aprovação imposta pelo processo de entrega. Uma política em uma wiki não é uma barreira.

Essa distinção importa porque a saída da IA muitas vezes parece mais completa do que realmente é. Uma alteração gerada pode compilar, seguir as convenções locais e incluir testes enquanto assume silenciosamente uma fronteira de confiança errada. Os revisores então gastam atenção com sintaxe e estilo porque o código parece familiar. Os controles abaixo devolvem a atenção às consequências.

O risco acompanha a autoridade, não as linhas de código

O risco em produção da assistência de IA para programação depende da autoridade que uma alteração recebe depois da implantação. Uma mudança de três linhas na autorização pode expor todos os clientes. Um grande conjunto de dados de teste gerado talvez nunca saia da máquina do desenvolvedor. Contar linhas, arquivos ou instruções geradas mede atividade, não perigo.

Classifique uma alteração perguntando o que ela pode fazer se estiver errada e quem consegue detectar a falha antes que o dano se espalhe. Uso quatro níveis práticos:

• Alterações verdes não alcançam dados de produção nem mudam uma decisão, como dados de teste isolados e documentação interna.
• Alterações amarelas afetam o comportamento comum da aplicação, mas têm impacto limitado e reversão rápida, como lógica de apresentação atrás de um sinalizador de recurso testado.
• Alterações vermelhas tocam uma fronteira de consequências graves: autenticação, pagamentos, infraestrutura, lógica clínica, migrações ou controles de segurança.
• Alterações pretas combinam uma fronteira de zona vermelha com recuperação fraca, pouca observabilidade ou um raio de impacto impossível de revisar. Elas exigem outro projeto, não uma aprovação mais corajosa.

A categoria preta impede um abuso comum da classificação de risco. Algumas equipes chamam uma migração perigosa de "alto risco", agendam um revisor adicional e prosseguem mesmo sem conseguir restaurar os dados. Nenhum revisor pode aprovar a ausência de uma rota de recuperação. O trabalho precisa mudar até que exista reversão, contenção ou recuperação ensaiada de verdade.

A mesma alteração pode mudar de nível conforme o contexto. Um adaptador de pagamentos gerado em um ambiente descartável é amarelo porque não consegue cobrar ninguém. Conectá-lo a credenciais de produção torna-o vermelho. Permitir reembolsos para todos os lojistas sem limite por transação nem mecanismo de interrupção pode torná-lo preto. Classifique a capacidade implantada, não a tarefa de desenvolvimento.

Isso também esclarece a diferença entre revisão e aprovação. A revisão encontra defeitos e melhora o código. A aprovação aceita um risco residual definido em nome da empresa ou da operação clínica. Um engenheiro sênior pode fazer as duas coisas em código rotineiro, mas zonas vermelhas precisam de um aprovador definido por função e domínio. Conhecer a linguagem de programação não qualifica alguém para aceitar uma consequência clínica ou financeira.

Alterações de autenticação precisam de um responsável por identidade

Qualquer alteração assistida por IA que crie, comprove, vincule, recupere ou revogue uma identidade pertence à zona vermelha de autenticação. Isso inclui manipuladores de login, criação de sessão, redefinição de senha, cadastro de múltiplos fatores, vinculação de contas, atributos de login único, credenciais de serviço e verificações de autorização que decidem qual identidade pode agir sobre qual recurso.

A barreira de aprovação deve exigir um responsável por identidade ou segurança que não tenha criado a alteração. Essa pessoa precisa de evidências para os casos reais de abuso, não apenas de um selo verde nos testes unitários. No mínimo, a alteração deve demonstrar negação de acesso entre clientes, invalidação de sessão após mudanças de credencial, resistência à repetição quando tokens são reutilizados, recuperação segura e negação por padrão quando faltam dados obrigatórios de identidade.

O OWASP Application Security Verification Standard separa autenticação, gerenciamento de sessão e controle de acesso porque passar por um deles não comprova os outros. Mesmo assim, equipes confundem essas áreas. Um login bem-sucedido comprova que o usuário apresentou credenciais aceitáveis. Não comprova que a sessão resultante tenha a duração correta, que o logout a revogue ou que o usuário possa ler um registro específico. Mantenha esses testes separados para que um caminho feliz gerado não esconda uma fronteira de autorização ausente.

Um artefato útil para a barreira é uma matriz de autorização armazenada no repositório. Ela mostra funções à esquerda, ações protegidas no topo e a decisão esperada de permitir ou negar em cada célula. A suíte de testes deve exercitar cada célula de negação que proteja um cliente, uma ação administrativa, uma operação de credencial ou um registro sensível. Assim, os revisores veem quando uma alteração muda uma decisão, em vez de descobrir a política lendo condições aninhadas.

Fluxos de recuperação merecem uma revisão adversária porque contornam de propósito a comprovação normal de identidade. Teste se um invasor consegue enumerar contas, redirecionar uma redefinição, reutilizar um link, manter uma sessão antiga após a recuperação ou substituir um fator forte por outro mais fraco. Agentes de suporte e administradores precisam do mesmo cuidado. Uma redefinição manual privilegiada ainda é um protocolo de autenticação, mesmo quando implementada em uma tela de suporte e em um procedimento escrito.

Não aceite "o modelo usou o middleware padrão do framework" como evidência. O middleware pode estar ligado à rota errada, executar depois do carregamento dos dados ou confiar em um atributo que outro serviço nunca validou. Inspecione todo o caminho da solicitação, desde a entrada não confiável até a ação protegida. Se um mapeamento de identidade atravessar serviços, registre emissor, público, mapeamento do sujeito, comportamento do relógio e premissa de revogação.

A barreira de implantação também deve separar a aprovação do código do acesso às credenciais. O artefato aprovado deve passar pelo processo sem fornecer segredos de produção à sessão do modelo, ao agente ou ao ambiente de instruções do desenvolvedor. Uma pessoa aprovar o código não remove segredos já expostos a um serviço externo. Se uma credencial entrou em uma instrução ou registro visível ao modelo, trate-a como divulgada e faça a rotação.

Código de pagamentos precisa comprovar invariantes monetárias

Alterações de pagamento assistidas por IA são vermelhas quando podem autorizar, capturar, reembolsar, liquidar, definir preço, tributar, creditar ou reconciliar valor real. A barreira precisa comprovar invariantes monetárias sob novas tentativas e falhas parciais, pois os defeitos de pagamento mais caros costumam ser operações aparentemente válidas executadas duas vezes ou registradas em apenas um sistema.

Comece com invariantes explícitas em linguagem comum. Uma solicitação de pagamento tem um lojista, uma moeda, um valor expresso na menor unidade aceita e uma chave de idempotência estável. Uma nova tentativa não pode criar uma segunda cobrança. Um reembolso não pode superar o valor capturado depois de reembolsos anteriores. Um estado local de "pago" não pode aparecer sem uma referência persistente para a operação externa. Essas afirmações devem se tornar testes e, quando possível, restrições no banco de dados.

O código de pagamento gerado costuma tratar a resposta de sucesso e considerar todo erro uma falha limpa. Redes de produção não funcionam assim. Um cliente pode exceder o tempo de espera depois que o processador aceitou a solicitação. A aplicação agora tem um resultado desconhecido, não um pagamento recusado. Tentar novamente com outra chave de idempotência pode cobrar duas vezes. Marque a operação como pendente, consulte pela chave ou referência original e reconcilie antes de decidir o que aconteceu.

Webhooks adicionam outra fronteira de incerteza. Autentique o remetente, preserve o identificador original do evento, confirme apenas depois da persistência e permita que o processamento se repita sem causar dano. Não presuma que a ordem de entrega corresponda à ordem dos negócios. Um aviso de reembolso pode chegar antes de um aviso atrasado de captura, e dois processos podem receber o mesmo evento. O manipulador deve registrar fatos e deixar uma máquina de estados explícita decidir se uma transição é permitida.

A barreira de aprovação deve exigir um responsável por pagamentos e um engenheiro que entenda a transação de armazenamento. Eles precisam de uma matriz de testes para solicitações duplicadas, tempos esgotados antes e depois da aceitação, callbacks fora de ordem, assinaturas inválidas, divergências de moeda, limites de arredondamento, reembolsos parciais e reconciliação após a falha de um processo. Use ambientes de teste do processador para o comportamento do protocolo, mas teste seu próprio estado persistente com falhas injetadas. Esses ambientes raramente reproduzem todos os problemas de ordenação.

Não deixe a IA inventar regras de pagamento com base em nomes como available_balance ou settled. Essas palavras têm significados comerciais e contábeis diferentes entre sistemas. Escreva uma tabela curta de transições de estado que liste cada transição permitida, o evento que a causa, a evidência persistente exigida e se um operador pode revertê-la. Rejeite transições fora da tabela mesmo que o código proposto pareça razoável.

A barreira de lançamento deve limitar a exposição. Encaminhe uma parcela pequena e observável pelo novo caminho, defina uma condição automática de parada e mantenha o caminho antigo disponível até a reconciliação coincidir. Um sinalizador de recurso não basta se sua desativação deixar callbacks aceitos sem processamento ou dividir uma transação entre duas implementações. O plano de reversão precisa incluir dinheiro em trânsito, não apenas os binários da aplicação.

Alterações de infraestrutura exigem um raio de impacto limitado

A infraestrutura entra na zona vermelha quando uma alteração gerada pode modificar identidade de produção, rede, criptografia, capacidade computacional, persistência, cópias de segurança, registros ou permissões de implantação. A aprovação deve depender de um plano legível por máquina, um alvo limitado e um teste de recuperação, não de o arquivo de configuração parecer convencional.

Para infraestrutura declarativa, preserve o plano exato aprovado pelos revisores e aplique esse artefato sem regenerá-lo com entradas diferentes. A barreira deve falhar se a conta, região, área de trabalho ou conjunto de recursos mudar entre o planejamento e a aplicação. Os revisores devem ver separadamente substituições, exclusões, ampliações de permissão, exposição pública e mudanças em recursos que armazenam dados.

A configuração gerada tem um padrão de falha específico: copia um exemplo válido, mas ignora as restrições ao redor que o tornavam seguro. Uma política ampla de identidade pode ser aceitável em uma conta descartável e desastrosa em uma conta compartilhada de produção. Uma regra de rede pode expor um serviço porque o exemplo pressupunha outra camada de firewall. O validador de sintaxe não enxerga essas premissas ausentes.

Exija verificações de política que respondam a perguntas concretas. Este plano pode criar uma porta pública? Pode conceder ações curinga? Pode desativar criptografia ou retenção? Pode destruir ou substituir um recurso com estado? Pode mudar a função do processo que impõe essas verificações? Uma alteração proposta na própria proteção nunca deve passar porque a proteção revisada a aprovou. Revise esse controle por um caminho independente.

A evidência de recuperação deve corresponder ao recurso. Para computação sem estado, pode bastar reimplantar uma versão já conhecida como boa. Para um banco de dados, fila, repositório de identidades ou chave criptográfica, um comando de reversão não comprova recuperação. Restaure uma cópia em um ambiente isolado, verifique leituras pela aplicação e registre a duração da recuperação e qualquer perda de dados sem inventar uma meta reconfortante.

Use implantação progressiva para reduzir a incerteza, mas não confunda uma versão canário com contenção. Uma política global de permissões, uma mudança de esquema compartilhado ou uma operação destrutiva de armazenamento pode afetar todas as instâncias mesmo que apenas uma réplica receba tráfego. Determine o raio de impacto pelo recurso alterado. Depois, exija um aprovador responsável por esse raio e um operador capaz de interromper a implantação.

Lógica clínica precisa de rastreabilidade e aprovação clínica

Software que influencia diagnóstico, triagem, medicação, dosagem, alertas, rotas de cuidado ou apresentação de fatos clínicos pertence à zona vermelha clínica. Um profissional licenciado ou responsável clínico formalmente designado deve aprovar o comportamento pretendido, enquanto a engenharia aprova separadamente a implementação e a operação. Uma aprovação não substitui a outra.

A barreira começa com uma declaração exata de uso pretendido: quem usa o resultado, para quais pacientes, com quais entradas, em qual ponto do atendimento e qual decisão ele pode influenciar. Sem essa fronteira, os revisores não conseguem decidir se uma falha é um incômodo ou um risco para o paciente. A IA tende especialmente a preencher lacunas com premissas plausíveis, portanto uma tarefa ambígua deve interromper o trabalho.

Crie rastreabilidade de cada requisito clínico até o código, os casos de teste e o comportamento exibido. Se uma regra diz que um alerta dispara sob condições definidas, as evidências devem incluir valores de limite, dados ausentes, dados conflitantes, unidades, tempo, substituições e o texto mostrado ao usuário. Um cálculo interno correto ainda pode causar dano se a interface ocultar incerteza ou apresentar informação antiga como atual.

Correção clínica é diferente de correção de software. Testes unitários podem provar que o código implementa uma fórmula. Não podem provar que a fórmula serve para a população pretendida, que os dados de origem têm o significado presumido ou que o fluxo dá tempo para um profissional agir. O revisor clínico responde por essas perguntas. O engenheiro responde por execução determinística, origem dos dados, tratamento de falhas, registros de auditoria e comportamento seguro quando as entradas não estão disponíveis.

Para alterações geradas por IA, armazene o requisito aprovado e as evidências, não uma instrução bruta no lugar deles. Instruções são registros úteis de desenvolvimento, mas não definem a intenção clínica com precisão suficiente para validar mudanças futuras. Um revisor deve conseguir ligar um comportamento de produção a um requisito controlado sem reproduzir uma conversa com o modelo.

A barreira de lançamento precisa de monitoramento ligado aos riscos clínicos. Acompanhe entradas ausentes, alertas suprimidos, caminhos de substituição, dados antigos, frequência inesperada de regras e divergências entre valores exibidos e armazenados. Defina quem recebe cada sinal e qual ação essa pessoa pode tomar. Se a única resposta for "investigar depois", o sistema não tem controle operacional.

Migrações só são seguras quando a recuperação é demonstrada

Migrações de dados e esquema tornam-se vermelhas quando transformam registros persistentes de produção, mudam a compatibilidade entre versões em execução, reconstroem índices com impacto operacional ou removem informações. A barreira de aprovação deve comprovar compatibilidade futura, segurança ao reiniciar, reconciliação e recuperação com dados semelhantes aos de produção.

A recomendação popular de "sempre tornar migrações reversíveis" é superficial demais. Uma migração de retorno pode desfazer uma instrução de esquema e ainda perder valores já transformados ou apagados. Ela também pode falhar depois que novas versões escreverem dados que o esquema antigo não representa. Você precisa de um plano de recuperação, que pode ser reversão, reparo para a frente, restauração ou uma combinação. Diga qual será usado de verdade.

Prefira mudanças de expansão e contração quando várias versões da aplicação puderem funcionar juntas. Adicione a nova estrutura sem remover a antiga, implante código que tolere ambas, preencha dados em lotes limitados, compare resultados, troque as leituras e remova a estrutura antiga apenas depois que a janela de compatibilidade se fechar. Cada etapa deve poder ser implantada e observada de forma independente.

Uma barreira de migração pode exigir um ensaio reproduzível:

1. Restaure uma cópia recente semelhante à produção em um ambiente isolado, com valores sensíveis protegidos.
2. Execute a migração usando o mesmo artefato, permissões, tempos de espera e coordenação planejados para produção.
3. Interrompa em vários limites de lote, reinicie e verifique se o trabalho repetido não corrompe resultados.
4. Compare contagens, somas ou hashes adequados aos dados, registros rejeitados e leituras pela aplicação antes e depois.
5. Exercite o caminho declarado de recuperação e registre o que ainda depende de trabalho manual.

Evite uma única soma de verificação sobre uma tabela mutável inteira. Ela informa que algo difere, mas não se a diferença era esperada nem onde começar o reparo. A reconciliação deve seguir partições e invariantes de negócio: por cliente, dia, moeda ou tipo de registro. Preserve registros rejeitados com os motivos para que operadores possam corrigi-los sem repetir toda a transformação às cegas.

O código de migração gerado merece atenção extra em valores nulos, padrões, codificação de caracteres, fusos horários, unidades, chaves duplicadas e conversões implícitas. Modelos deduzem o caso comum pelos nomes. Seus dados históricos contêm exceções criadas por versões antigas, reparos manuais e integrações que já não existem. Selecione essas exceções de propósito para os testes.

Não aprove uma etapa final destrutiva apenas porque as anteriores funcionaram bem. A remoção muda as opções de recuperação. Exija outra aprovação depois do período de observação, com evidências de que nenhum código aceito lê ou grava a representação antiga e de que as cópias mantidas atendem à necessidade real de recuperação.

Controles de segurança não podem aprovar o próprio enfraquecimento

Alterações em política de autorização, tratamento de segredos, criptografia, registro de auditoria, validação de entrada, controles de dependência, monitoramento de segurança ou proteções de entrega são vermelhas mesmo quando não tocam uma função do produto. A barreira deve ser independente do controle alterado.

Essa regra de independência é fácil de explicar e fácil de violar. Imagine que uma alteração gerada por IA modifique a regra do processo que bloqueia falhas críticas em dependências, e que a mesma solicitação seja aprovada porque a regra alterada deixou de bloqueá-las. A marca verde não significa nada. A alteração usou sua própria definição nova de segurança para aprovar a si mesma.

Proteja as definições de controle com responsáveis e aplicação separados. Alterações em proteções de ramificação, mecanismos de política, limites de análise, exclusões de registro, funções privilegiadas e barreiras de implantação devem exigir revisão do responsável por segurança e ser aplicadas somente depois que o controle antigo aprovar a transição. Quando isso for impossível, use um caminho administrativo com registros explícitos e uma segunda pessoa.

O NIST Secure Software Development Framework trata a proteção do software e a produção de versões bem protegidas como práticas contínuas, não como uma verificação final. Essa visão está certa. Uma alteração gerada pode passar por um analisador e ainda remover um campo de registro necessário para responder a incidentes, ampliar uma fronteira de confiança ou transformar uma falha obrigatória em um aviso ignorado. As evidências precisam cobrir prevenção, detecção e recuperação relevantes para o controle alterado.

Rejeite explicações como "esta exceção é temporária" a menos que ela tenha um responsável, escopo estreito, prazo e condição de remoção registrada. Uma exceção permanente costuma começar como saída para cumprir um prazo. A barreira deve impor a expiração, em vez de depender de alguém se lembrar depois do lançamento.

Segredos precisam de uma regra própria. Nunca coloque segredos de produção, dados privados de pacientes, dados de pagamento ou código-fonte proprietário fora da fronteira aprovada para o modelo. A ocultação só ajuda quando o sistema entende os formatos e age antes da transmissão. Se dados sensíveis chegarem a um modelo ou registro não aprovado, trate o incidente imediatamente; apagar a conversa não desfaz a divulgação.

Barreiras de aprovação precisam de evidências e separação

Uma barreira útil para zona vermelha é um contrato aplicável com cinco partes: escopo, evidência, aprovador, restrição de implantação e autoridade de recuperação. Se qualquer parte for vaga, a barreira vira uma caixa cerimonial que os revisores aprendem a marcar.

O escopo identifica caminhos, recursos, classificações de dados e mudanças semânticas que acionam a barreira. Caminhos de arquivos isolados são fracos porque bibliotecas compartilhadas e configurações geradas podem alterar uma zona vermelha de forma indireta. Combine regras de caminho com metadados de responsabilidade, análise do plano de infraestrutura, detecção de operações de banco de dados e uma declaração na solicitação de alteração que os revisores possam contestar.

Permita que desenvolvedores contestem uma classificação automática, mas nunca que o autor a rebaixe em silêncio. A contestação deve nomear a zona proposta, explicar a consequência limitada e receber aprovação do responsável pela zona original. Isso evita que falsos positivos transformem a política em ruído e preserva um registro do motivo pelo qual a barreira não se aplicou. Revise periodicamente essas exceções para encontrar padrões repetidos que deveriam virar regras de classificação melhores.

As evidências devem corresponder à falha. Autenticação precisa de casos de negação e testes de sessão. Pagamentos precisam de testes de nova tentativa, reconciliação e invariantes. Infraestrutura precisa de um plano revisado e evidências de recuperação. Lógica clínica precisa de requisitos controlados e validação clínica. Migrações precisam de ensaio e reconciliação. Controles de segurança precisam de aprovação independente. Uma porcentagem genérica de cobertura não substitui nenhum deles.

Os aprovadores devem ser funções com membros atuais identificados, não qualquer pessoa que seja sênior. Exija pelo menos um aprovador do domínio, independente do autor, para cada alteração em zona vermelha. Para comportamento clínico ou regras financeiras importantes, adicione o responsável operacional designado. Impeça que o agente de IA, a conta de serviço ou o autor satisfaça a aprovação por meio de uma identidade automatizada.

Restrições de implantação limitam o que acontece depois da aprovação. Vincule a aprovação a um commit e ao resumo criptográfico do artefato para que uma regeneração posterior não passe escondida. Separe credenciais de produção do ambiente de programação. Use exposição gradual quando ela realmente limitar o impacto, defina condições de parada e permita que a pessoa de plantão interrompa a implantação sem esperar pelo autor.

A autoridade de recuperação identifica a pessoa que pode desativar, reverter, restaurar ou reparar para a frente e fornece o acesso necessário antes do lançamento. Um incidente é a pior hora para descobrir que apenas um administrador ausente pode restaurar uma cópia. Ensaie o acesso e também os comandos.

Este trecho de política mostra o registro mínimo que espero que um sistema de entrega imponha:

zone: payments
change_digest: "sha256:<artifact-digest>"
required_approvals:
  - role: payments_owner
    independent_of_author: true
evidence:
  - retry_matrix
  - reconciliation_report
deployment:
  max_exposure_percent: 5
  stop_condition: "duplicate_or_unreconciled_transaction"
recovery_owner: "on_call_payments"

A sintaxe exata não importa. O trecho impede que a aprovação se afaste do artefato e que o risco seja aceito sem evidência ou responsável. Armazene esse registro com a versão para que uma análise de incidente consiga reconstruir o que era conhecido e quem aceitou o risco restante.

Revisão humana precisa significar controle responsável

A revisão humana só reduz o risco da assistência de IA para programação quando a pessoa tem competência, informação, tempo, autoridade e independência para interromper a alteração. Um revisor cansado que aprova uma grande mudança gerada oferece presença humana, não controle humano.

Mantenha alterações geradas pequenas o bastante para serem compreendidas. Peça um comportamento limitado, exija que o modelo ou o desenvolvedor declare as premissas e rejeite limpeza sem relação com uma alteração de zona vermelha. Execute formatadores e analisadores determinísticos, mas faça o autor explicar com suas próprias palavras as fronteiras de confiança, estados de falha e recuperação. Se a explicação não resistir a perguntas, o código não está pronto.

Meça a barreira pelos resultados que revelam sua condição. Acompanhe com que frequência revisores pedem mudanças substanciais, faltam evidências, exceções de emergência expiram, recuperações ensaiadas funcionam e uma pessoa aprova repetidamente domínios que não conhece. Não recompense apenas a velocidade de aprovação. Uma aprovação rápida pode indicar uma alteração clara ou que ninguém analisou.

A IA pode ser útil antes da barreira. Ela pode enumerar casos extremos, rascunhar testes, comparar uma alteração com uma tabela de estados e apontar inconsistências. Trate essas saídas como pistas. O mesmo modelo que criou um defeito pode criar com confiança um teste que confirma sua própria premissa errada, portanto requisitos independentes e julgamento humano continuam necessários.

A SaaS Production usa IA com engenheiros experientes e uma abordagem Human-in-the-Loop para reduzir o tempo de entrega e manter o controle humano. Em trabalho de zona vermelha, essa abordagem deve aparecer no histórico dos artefatos: quem definiu a fronteira, quais evidências foram inspecionadas, qual exposição foi aceita e como a equipe pode se recuperar.

Não existe uma porcentagem responsável de código que a IA possa escrever em todos os sistemas. Defina zonas vermelhas pelas consequências, incorpore as barreiras às ferramentas de entrega e recuse a implantação quando a recuperação existir apenas como uma frase em uma tarefa. Se uma equipe não consegue nomear a pessoa autorizada a interromper uma mudança perigosa, a alteração não está pronta para produção.

Perguntas Frequentes

A IA pode escrever código para sistemas de autenticação?

Sim, mas código de autenticação pertence a uma zona vermelha. Um responsável independente por identidade ou segurança deve aprová-lo depois de testar negações, sessões, recuperação e fronteiras de autorização.

O que torna arriscado o código de pagamento gerado por IA?

Novas tentativas, callbacks atrasados e falhas parciais podem criar transações duplicadas ou sem reconciliação mesmo quando o caminho feliz parece correto. A barreira deve comprovar idempotência, transições de estado, invariantes de valor e moeda e recuperação para resultados desconhecidos.

Agentes de IA devem receber credenciais de produção?

Não. Mantenha credenciais fora do modelo e do ambiente do agente, e faça um artefato aprovado passar por um processo de entrega separado. Se um segredo entrar em uma instrução ou registro visível ao modelo, trate-o como divulgado e faça a rotação.

A revisão humana basta para código gerado por IA?

Somente quando o revisor tem competência de domínio, evidências, tempo e autoridade para interromper o lançamento. Zonas vermelhas também precisam de restrições de implantação impostas e de um responsável por recuperação.

Como equipes devem classificar o risco de programação com IA?

Classifique a autoridade e as consequências implantadas, não a quantidade de código gerado. Uma alteração pequena é vermelha se puder mudar identidade, dinheiro, infraestrutura compartilhada, decisões clínicas, dados persistentes ou um controle de segurança.

Quais evidências uma aprovação de infraestrutura deve incluir?

Revise o plano exato legível por máquina que será aplicado, com conta alvo e escopo de recursos fixos. Separe exclusões, substituições, exposição pública, ampliação de permissões, recursos com estado e a prova de que a recuperação funciona.

Uma migração reversível ainda pode ser insegura?

Sim. Uma migração de retorno pode reverter o esquema e perder dados transformados ou rejeitar valores escritos pela nova aplicação. Exija recuperação ensaiada, lotes reiniciáveis, compatibilidade e reconciliação de negócio.

Quem aprova lógica clínica assistida por IA?

Um responsável clínico designado aprova o comportamento e as consequências clínicas, enquanto a engenharia aprova implementação e operação. O lançamento também precisa de rastreabilidade entre requisitos controlados, testes e comportamento exibido.

Como impedir controles de segurança de aprovarem a si mesmos?

Use responsáveis separados e um caminho independente de aplicação para políticas, limites de análise, funções privilegiadas, exclusões de registro e barreiras de entrega. Sempre que possível, o controle antigo deve aprovar a transição.

Quando uma alteração assistida por IA deve ser totalmente bloqueada?

Bloqueie quando o raio de impacto não estiver limitado, a recuperação não tiver sido demonstrada, faltarem evidências obrigatórias ou nenhum responsável qualificado aceitar o risco residual. Esses são defeitos de projeto, não motivos para adicionar outro revisor apressado.