Segurança de IA é sobretudo design de sistemas.
A reunião de segurança depois da demonstração
A demonstração tinha corrido bem, como de costume. O modelo leu uma pilha de documentos internos, respondeu a uma pergunta sobre políticas, sugeriu um passo seguinte e produziu um resumo arrumado para o processo. A sala assentiu. Alguém perguntou se podia ser ligado ao sistema de fluxo de trabalho. Outra pessoa perguntou para quando. Depois, o responsável pela segurança perguntou o que aconteceria se o modelo estivesse errado, mas fosse convincente. A sala ficou subitamente muito interessada nos biscoitos.
É aí que começa a segurança prática da IA. Não no abstrato, nem num slogan. Na forma do sistema à volta de um modelo que, por vezes, estará errado, por vezes desatualizado, por vezes demasiado confiante, por vezes pouco confiante e, por vezes, correto pela razão errada. A questão de segurança não é apenas o comportamento do modelo. É aquilo que o sistema permite que esse comportamento faça.
Um modelo que redige uma frase é um risco. Um modelo que atualiza uma decisão de prestações é outro. Um modelo que chama uma ferramenta com acesso de escrita é outro. Um modelo que encaminha um doente, recusa um pedido, altera um limite de crédito ou controla equipamento está numa classe de perigo completamente diferente. O mesmo modelo subjacente pode ser inofensivo, útil, arriscado ou inaceitável, consoante os limites, o estado, as provas, a autoridade, a monitorização e a recuperação. É por isso que a segurança da IA é, sobretudo, uma questão de conceção de sistemas.
Sobretudo está a fazer trabalho nessa frase. A investigação sobre modelos é importante. A qualidade dos dados é importante. Os métodos de alinhamento são importantes. A ciência da avaliação é importante. Mas quando uma organização implementa IA, a segurança torna-se operacional. Quem pode perguntar. O que o modelo pode ver. O que pode alterar. Que provas são exigidas. Que estado é preservado. O que acontece quando as fontes discordam. Quando é que um humano tem de aprovar. Como se deteta a deriva. Como se reverte uma má versão. São questões de conceção antes de serem declarações de ética. A declaração de ética pode ser sincera. O sistema não executa sinceridade.
A segurança é um problema de controlo
Quando as pessoas ouvem falar de segurança, pensam muitas vezes em valores, dados de treino, políticas de recusa e alinhamento do modelo. Isso faz parte do quadro, mas um sistema implementado também precisa de controlos. Um controlo é algo que altera o que pode acontecer: uma verificação de acesso, um esquema, um tempo limite, um limiar, uma aprovação humana, uma sandbox, um limite de velocidade, um verificador, uma reversão, um interruptor de emergência, um registo que não pode ser editado pelo caminho de serviço. Os controlos são aborrecidos até faltarem. Depois, tornam-se a reunião inteira.
Um sistema de IA seguro parte do princípio de que o modelo pode falhar e desenha a maquinaria à sua volta em conformidade. Separa a sugestão da ação. Limita a autoridade das ferramentas. Verifica as evidências antes de alterar o estado. Torna a incerteza visível. Regista a versão do modelo e o âmbito das fontes. Recusa-se quando faltam campos obrigatórios. Dá aos operadores uma forma de pausar a automatização. Trata o resultado do modelo como um candidato, não como um decreto de uma folha de cálculo muito eloquente.
Isto é engenharia de segurança comum com um modelo de linguagem no meio. A aviação, a medicina, o caminho de ferro, o controlo industrial e as finanças aprenderam que sistemas importantes precisam de controlos em camadas porque nenhum componente é perfeito. A versão com IA parece nova porque o componente fala. A fala torna o erro socialmente persuasivo. Uma resposta errada que soa calma pode passar despercebida a um operador cansado com mais facilidade do que um erro vermelho intermitente. O desenho do controlo tem, por isso, de ser mais teimoso do que a prosa.
O desenho do controlo começa por perguntar o que o sistema pode afetar. Se a IA só pode redigir, a segurança centra-se na qualidade das fontes, na verificação de alucinações, na clareza da interface e na revisão. Se pode encaminhar trabalho, a segurança acrescenta o acompanhamento do estado, a integridade das filas, os níveis de serviço e as vias de recurso. Se pode chamar ferramentas, a segurança acrescenta âmbitos de permissão, validação de argumentos, registos de transações e ações compensatórias. Se pode afetar direitos ou sistemas físicos, a segurança exige prova, revisão formal, autonomia restrita e planeamento sério de incidentes. O modelo é uma parte. O envelope de autoridade é a outra.
O limite é o produto
A linha mais importante num sistema de IA muitas vezes não é visível na interface. É o limite entre ler e escrever, recomendar e decidir, resumir e registar, assistir e agir. Limites fracos são como protótipos inofensivos se tornam serviços inseguros. Um modelo que começa como auxiliar de redação ganha um botão para aplicar o rascunho. Depois ganha uma ferramenta para atualizar o processo. Depois ganha uma regra de encaminhamento porque a equipa está ocupada. Seis meses depois, ninguém consegue explicar quais decisões são automatizadas e quais são apenas assistidas. Isto não é malícia. É expansão de âmbito com sapatos confortáveis.
Bons limites são explícitos e inspecionáveis. O modelo pode ler estas fontes, não aquelas. Pode propor estes campos, não os confirmar. Pode chamar esta ferramenta com estes argumentos, não com texto arbitrário. Pode encaminhar casos de baixo risco, não casos contestados. Pode responder apenas quando as evidências são atuais. Não pode usar notas privadas para explicações públicas. Não pode passar de um inquilino, região, conta ou base jurídica para outra porque o parágrafo seguinte parecia útil.
Os limites também precisam de ser aplicados fora do modelo. Um prompt que diz para não escrever na base de dados de clientes não é um limite se a ferramenta tiver acesso de escrita e não tiver gateway. Uma mensagem de sistema que diz para citar fontes não é um limite se as respostas puderem ser armazenadas sem citações. Um parágrafo de política que diz que é necessária aprovação humana não é um limite se o fluxo de trabalho permitir que a automatização marque como aprovado. As instruções de segurança dentro do modelo são úteis, mas não chegam. O sistema tem de tornar os caminhos inseguros difíceis ou impossíveis.
Este é o trabalho sem romantismo que realmente protege as pessoas. Chamadas de ferramentas tipadas. Âmbitos estreitos. Predefinições só de leitura. Serviços de aprovação separados. Operações idempotentes. Registos de auditoria. Políticas com versões. Estados de fila. Estados explícitos de recusa. O vocabulário parece que um engenheiro de backend teve um fim de semana tranquilo com uma prancheta. Bem. A segurança em produção costuma ser assim. Não está a tentar ganhar um concurso de slogans.
O estado é onde a segurança se torna real
As conversas com IA podem fazer os sistemas parecerem sem estado. Um utilizador pergunta, um modelo responde, o ecrã muda. A produção não é sem estado. Os processos avançam. Os pedidos envelhecem. As permissões expiram. Os documentos são corrigidos. A versão de um modelo muda. Um humano anula uma recomendação. Chega um recurso. Um utilizador pergunta por que algo aconteceu no mês passado. A segurança depende de o sistema ter preservado o estado necessário para responder.
O estado diz ao sistema o que já aconteceu e o que pode acontecer a seguir. Sem ele, o modelo vê um fragmento e adivinha o resto. É assim que acontecem ações duplicadas, prazos que desaparecem, aprovações assumidas e provas antigas que voltam a entrar numa nova decisão. Um fluxo de trabalho seguro regista estados explícitos: rascunho, provas em falta, bloqueado por política, revisão necessária, aprovado, executado, contestado, corrigido, recolhido. Estes estados não são decorativos. Impedem o modelo de tratar um processo consequente como uma transcrição de conversa com ambições.
O estado também dá alavancagem aos humanos. Um operador pode inspecionar por que um processo está em revisão. Um gestor pode ver se a automatização está a criar um atraso. Um auditor pode reproduzir quais versões de fontes estavam ativas. Um utilizador pode contestar um resultado com algo mais sólido do que uma captura de ecrã. Um programador pode medir se um novo modelo aumenta recusas, escalonamentos ou retrabalho. Sem estado, qualquer conversa sobre segurança torna-se teatro. As pessoas falam em responsabilidade, mas o sistema perdeu os substantivos.
Para a IA, o estado deve incluir a versão do modelo e da política, o identificador do prompt ou do modelo de texto, o conjunto de fontes, o carimbo temporal da recuperação, as chamadas de ferramentas, a confiança ou incerteza, o motivo da recusa, a ação humana e o efeito a jusante. Nem tudo isto cabe numa única linha de registo, e nem tudo deve ser visível para todos. A privacidade e a segurança importam. Mas a informação deve existir sob acesso controlado. Caso contrário, a segurança fica dependente da memória, e a memória é uma base de dados notoriamente má com excelentes desculpas.
As provas são o corrimão da segurança
Uma resposta de um modelo é mais segura quando está ligada a provas. Isto parece óbvio até o sistema estar sob pressão. As provas são ignoradas porque acrescentam latência. As citações são guardadas como texto em vez de identificadores. As pontuações de recuperação não são preservadas. As versões das fontes são sobrescritas. O modelo escreve uma explicação confiante a partir de um documento que entretanto foi corrigido. Mais tarde, todos perguntam por que a resposta estava errada. A resposta é que o corrimão era decorativo.
Prova útil não é uma nota de rodapé. É uma cadeia. O pedido entrou com uma identidade e um propósito. As fontes foram selecionadas sob permissão. A recuperação encontrou blocos ou registos específicos. O modelo produziu um resultado sob uma versão nomeada. Um verificador confirmou alegações ou limiares. Um humano aceitou, editou ou rejeitou. A ação alterou o estado. O sistema guardou o suficiente dessa cadeia para a reproduzir ou contestar. Isto não é burocracia por si só. É assim que a segurança sobrevive ao tempo.
A prova também protege o modelo de ser obrigado a fazer trabalho impossível. Se o sistema exigir fontes atuais, o modelo pode recusar dados desatualizados. Se o sistema exigir dois registos correspondentes, pode assinalar a divergência. Se o sistema exigir identificadores de fonte, pode travar alegações sem suporte. O modelo deixa de ter de transformar provas em falta numa gestão fluente de incerteza. Pode devolver um estado seguro. Isto é mais gentil para o modelo e muito mais gentil para a pessoa afetada pelo resultado.
Há um equilíbrio. A captura de prova não deve tornar-se vigilância. Conteúdo sensível pode ser cifrado, redigido, separado ou retido por períodos limitados. A questão não é registar tudo para sempre. A questão é preservar os factos necessários para inspecionar comportamentos importantes. Segurança sem prova é apenas confiança com um casaco mais bonito. Pode parecer bem no átrio. Não se sustenta num incidente.
Os humanos precisam de autoridade desenhada
Human in the loop é muitas vezes usado como uma frase mágica. Não é magia. Um revisor cansado, com provas fracas, política pouco clara e uma fila de duzentos casos não é um sistema de segurança. É uma pessoa colocada no fim de uma linha de montagem a quem pedem que seja governança. Pode funcionar por pouco tempo, especialmente se a pessoa for experiente e teimosa. Não é um desenho.
A autoridade humana tem de ser específica. Que casos exigem revisão. Que provas o revisor vê. Pode o revisor alterar campos estruturados ou apenas aprovar prosa. Sabe o revisor se o modelo estava incerto ou se a política exigia escalada. As divergências são devolvidas à avaliação. Os revisores estão protegidos do viés de automação. Podem pausar um fluxo de trabalho. Podem escalar para um especialista. Podem ver casos semelhantes anteriores. Podem explicar uma decisão à pessoa afetada. Estes detalhes decidem se a supervisão humana é real ou ornamental.
Uma boa supervisão também separa o julgamento da recuperação administrativa. As pessoas não devem gastar o seu tempo a encontrar identificadores de origem em falta, a eliminar duplicados em novas tentativas, a traduzir o texto do modelo em estados de fluxo de trabalho ou a adivinhar qual versão da política foi aplicada. O sistema deve preparar o processo. O ser humano deve aplicar o julgamento onde ele é necessário: significado contestado, exceção, proporcionalidade, contexto, empatia e responsabilidade. Se o ser humano passa a maior parte do tempo a corrigir lacunas de infraestrutura, a organização confundiu pessoal com segurança.
O design também deve permitir que os seres humanos discordem da automatização sem que o atrito se torne um castigo. Se anular o modelo exige oito cliques e aceitar exige um, a interface tem uma política. Se a escalada faz uma equipa parecer lenta, as pessoas vão evitá-la. Se as métricas recompensam apenas o volume, as revisões de segurança tornar-se-ão cerimoniais. O design de sistemas inclui incentivos, ecrãs, filas e predefinições. O modelo pode não conhecer a métrica, mas as pessoas certamente conhecerão.
A localidade altera o risco
Onde o trabalho de IA acontece é importante. Um sistema que envia todos os documentos para um modelo remoto tem riscos diferentes de um que faz a extração perto dos dados e envia apenas um campo derivado. Um sistema que armazena registos no serviço de disponibilização tem riscos diferentes de um que mantém registos de auditoria independentes. Um sistema que depende de um único router externo tem opções de recuperação diferentes de um que pode degradar-se localmente. A localidade não é nacionalismo com um diagrama de rede. É a questão prática de quais riscos se movem quando dados, computação, política e provas se movem.
Algum trabalho deve acontecer perto de dados sensíveis porque mover os dados cria exposição. Algum trabalho deve acontecer perto dos utilizadores porque a latência afeta a segurança. Algum trabalho deve acontecer num serviço central porque é necessária uma revisão especializada ou hardware. Algumas provas devem ser armazenadas fora do caminho de disponibilização do modelo porque esse caminho pode ser o objeto sob investigação. O design seguro raramente é tudo local ou tudo remoto. É uma colocação deliberada.
A localidade também afeta a responsabilidade legal e organizacional. Se uma chamada de modelo cruza regiões, que lei rege os dados. Se um índice é construído fora do sistema de origem, como são propagadas as eliminações. Se um fornecedor altera um modelo, como é recebido o aviso e como são realizados os testes. Se os registos estão num portal do fornecedor, pode a organização exportá-los durante um incidente. Estas não são questões abstratas de soberania. São questões de segurança porque determinam se a organização pode controlar e explicar o sistema sob pressão.
A colocação errada pode tornar o comportamento seguro caro. Se cada passo de verificação exigir uma viagem de ida e volta remota, as equipas podem amostrar em vez de verificar todos os casos. Se os dados de auditoria forem difíceis de cruzar, as investigações tornam-se lentas. Se dados privados tiverem de viajar para uma classificação simples, o risco aumenta sem ganho. Um bom design de localidade reduz o custo de fazer o que é seguro. Isto é importante porque os controlos demasiado caros acabarão por ser descritos como opcionais, e é assim que começam muitas histórias más.
A avaliação tem de acompanhar o sistema
Muitas equipas avaliam o modelo e esquecem-se de avaliar o sistema. Testam se as respostas estão corretas num conjunto de pedidos e depois implementam num fluxo de trabalho com permissões, frescura das fontes, filas, chamadas de ferramentas, revisão humana, tentativas e políticas em mudança. A referência do modelo pode continuar a ser útil, mas já não descreve todo o risco. As falhas de segurança vivem muitas vezes nas ligações.
Uma avaliação de sistema testa o comportamento de ponta a ponta. Pergunta se a fonte certa é obtida para o utilizador certo. Verifica se os dados desatualizados são recusados. Confirma que as chamadas de ferramentas são bloqueadas sem permissão. Mede se os casos de alto risco chegam a humanos. Testa a reversão. Testa o atraso das filas. Testa os caminhos de atualização do modelo. Testa casos estranhos mas comuns: data em falta, cliente duplicado, exceção regional, recurso após correção, eliminação de fonte, interrupção parcial, revisor sobrecarregado. A produção tem um gosto pelos casos que ninguém achava suficientemente dramáticos.
A avaliação deve incluir capacidade negativa. O sistema tem de ser bom a não fazer coisas. Não responder sem provas. Não cruzar limites de permissão. Não escalar para ação quando apenas é permitido redigir. Não esconder a incerteza. Não usar uma fonte depois de eliminada. Não continuar quando uma ferramenta devolve um estado inconsistente. A segurança depende tanto da recusa e da pausa como da exatidão. O resultado mais importante de um sistema de IA seguro pode ser provas insuficientes, o que é uma frase que nenhuma equipa de demonstração coloca num cartaz.
A avaliação do sistema também muda a gestão de lançamentos. Uma alteração de pedido, uma alteração de modelo, uma reconstrução de índice, uma atualização de política, uma alteração de permissão de ferramenta ou uma alteração na interface do revisor pode alterar a segurança. Cada uma precisa de um âmbito de teste e de um plano de reversão. A equipa deve saber quais os comportamentos que mudaram e quais os riscos que aumentaram. Isto é aborrecido da mesma forma que os cintos de segurança são aborrecidos. Só se torna interessante quando está ausente, o que é tarde demais para conforto.
A lição
A segurança da IA é sobretudo design de sistemas porque o dano costuma viajar através de sistemas. Uma saída do modelo torna-se arriscada quando um fluxo de trabalho confia demasiado nela, um portão de ferramentas é demasiado largo, faltam provas, o estado é vago, a revisão está sobrecarregada, os registos são fracos ou a reversão é imaginária. O modelo pode ser a fonte visível da frase, mas é o sistema que decide se a frase se torna ação.
Esta perspetiva é menos dramática do que muitos debates sobre segurança de IA e mais útil para organizações que implementam sistemas agora. Pede às equipas que definam limites, nomeiem responsabilidades, preservem provas, desenhem estados, distribuam o trabalho de forma deliberada, avaliem de ponta a ponta e deem aos humanos poder real. Trata o modelo como um componente poderoso num caso de segurança, não como o caso de segurança inteiro. Essa é a posição madura. Também dá aos engenheiros algo para construir além de outro PDF de políticas, o que é gentil para todos.
A pergunta do responsável de segurança após a demonstração estava exatamente certa. O que acontece se o modelo estiver errado mas for convincente. Um sistema seguro deve ter uma resposta: aqui só pode redigir, ali tem de citar fontes atuais, não pode chamar aquela ferramenta, este caso vai para revisão, esta ação deixa um recibo, este fluxo de trabalho pode ser pausado, esta versão pode ser revertida, esta decisão pode ser contestada. Essas respostas não são impressões. São design.
Haverá sempre incerteza na IA. A tarefa prática é impedir que a incerteza se torne autoridade ilimitada. Isso faz-se com interfaces, estados, controlos, provas, localidade, avaliação, recuperação e julgamento humano devidamente equipado. Por outras palavras, design de sistemas. Não porque os valores não importem, mas porque os valores têm de ser tornados executáveis antes de poderem proteger alguém.