Arquitetura de cibersegurança para agentes e soluções de inteligência artificial

Caso transversal · Cibersegurança

Cibersegurança by Design em Soluções de IA

O modelo pode interpretar uma intenção. Não deve decidir sozinho se tem autorização para a executar.

Um caso transversal, construído a partir de vários projetos

Este não é o relato de uma única instalação. É um caso técnico transversal que reúne padrões aplicados pela BigLearn em soluções para seguros, saúde, Administração Pública, hotelaria e comércio: assistentes baseados em conhecimento, tratamento de reclamações, canais com dados sensíveis, fluxos de encomendas e agentes ligados a processos internos.

Os clientes estão anonimizados e não publicamos métricas de incidentes que não possam ser demonstradas. O resultado verificável é a arquitetura: onde termina a linguagem, onde começa a autorização, que dados podem circular e em que ponto uma pessoa tem obrigatoriamente de decidir.

O erro perigoso: confundir inteligência com autoridade

Um modelo de linguagem é útil porque aceita entradas ambíguas: um email, uma reclamação, uma pergunta comercial ou um documento. Essa mesma flexibilidade cria a superfície de ataque. O conteúdo recebido pode incluir instruções hostis; um documento recuperado pode estar desatualizado ou contaminado; e uma resposta plausível pode continuar factualmente errada.

A decisão de arquitetura foi tratar entrada, contexto recuperado e saída do modelo como dados não confiáveis. O modelo interpreta e propõe. Componentes determinísticos verificam identidade, autorização, esquema, limites e estado do processo antes de qualquer ação.

Threat model antes do primeiro prompt

Em cada fluxo começámos por identificar ativos, fronteiras de confiança e efeitos possíveis. Os ativos não eram apenas bases de dados: incluíam instruções do sistema, documentos internos, identidade dos utilizadores, credenciais de integração, histórico de conversas e a própria capacidade de enviar, alterar ou classificar informação.

O cenário adversarial incluía prompt injection direta e indireta, fuga de contexto, acesso entre clientes, abuso de ferramentas, parâmetros manipulados, respostas sem fonte, repetição de pedidos, excesso de dados nos logs e escalada indevida de privilégios. Isto muda a pergunta de «o modelo responde bem?» para «o que acontece quando responde mal?».

A arquitetura: cinco fronteiras em vez de um prompt gigante

1 · EntradaIdentidade e origem

Canal, sessão, autenticação, limites de utilização e validação inicial.

2 · ContextoRecuperação autorizada

Fontes permitidas, filtradas pelas permissões antes de chegarem ao modelo.

3 · ModeloInterpretação

Produz resposta ou intenção estruturada; não recebe credenciais nem autoridade direta.

4 · PolíticaValidação determinística

Esquema, autorização, regras de negócio, risco e necessidade de confirmação.

5 · EfeitoFerramenta mínima

Uma função limitada executa, regista o resultado ou encaminha para uma pessoa.

Os controlos técnicos aplicados

Separação entre instruções e conteúdo

As regras permanentes do sistema não são misturadas com emails, documentos ou texto recuperado. O conteúdo externo é delimitado e classificado como dados a analisar, nunca como novas instruções a obedecer.

Saída estruturada e validação por esquema

Quando a IA identifica uma categoria, morada, produto ou ação, devolve campos estruturados. Tipos, formatos, valores permitidos e campos obrigatórios são validados fora do modelo; texto livre não é convertido diretamente numa operação.

Ferramentas em allowlist

O agente só vê as operações necessárias ao caso. Consultar não implica alterar; preparar não implica enviar. Cada ferramenta tem parâmetros estreitos e uma identidade técnica com privilégios mínimos.

RAG com controlo de acesso

A pesquisa semântica não contorna permissões. O universo documental é filtrado antes da recuperação, as fontes acompanham a resposta e a ausência de evidência produz abstenção ou encaminhamento — não invenção.

Confirmação proporcional ao impacto

Responder a horários é diferente de alterar um pedido, encaminhar uma denúncia ou produzir uma decisão com efeitos numa pessoa. As ações são classificadas por risco e as de maior impacto ficam pendentes de confirmação humana.

Observabilidade sem transformar logs num arquivo paralelo

Registam-se versões, fontes, chamadas de ferramentas, autorizações, erros e correlação entre etapas. O conteúdo integral e os dados pessoais não são registados por defeito: finalidade, acesso e retenção têm de ser explícitos.

linguagem não confiável → intenção estruturada → validação de política → autorização → execução mínima → registo → resposta

Prompt injection: o filtro não é a solução

Uma instrução como «ignora as regras anteriores» é o exemplo mais simples. O problema real é indireto: a instrução pode estar num PDF, numa página consultada pelo agente ou num email que parece uma reclamação legítima. Tentar reconhecer todas as frases perigosas é uma defesa útil, mas incompleta.

A defesa eficaz reduz o impacto possível: o documento não redefine a política; o modelo não conhece segredos; as ferramentas são limitadas; os argumentos são validados; uma operação sensível exige autorização independente. Assim, mesmo quando uma tentativa passa pela camada linguística, encontra uma fronteira técnica que não fala «linguagem de prompt».

RAG seguro: encontrar um documento não é ter autorização para o revelar

Nas soluções baseadas em conhecimento, a recuperação é condicionada pela identidade e pelo contexto do pedido. A filtragem acontece antes de os excertos serem enviados ao modelo. Isto evita que o modelo receba informação à qual o utilizador não tinha acesso e tente depois «esquecê-la» na resposta — uma proteção que seria demasiado tarde.

O conhecimento empresarial fica separado do modelo. Pode ser atualizado, versionado e retirado sem treinar novamente o sistema. Quando não existe fonte suficiente, a resposta correta pode ser não responder, pedir contexto adicional ou entregar o caso a uma pessoa.

O padrão aplicado em vários setores

Seguros: o assistente consulta conhecimento aprovado, recolhe dados progressivamente e entrega parâmetros a um processo determinístico. O cálculo pertence ao motor de negócio; o modelo não inventa prémios nem toma uma decisão de subscrição.

Saúde e canais sensíveis: a IA pode organizar um relato e extrair informação útil, mas não decide sobre pessoas. Acesso, conservação e encaminhamento são definidos pelo processo, e a decisão final permanece humana.

Administração Pública: emails e reclamações são entradas não confiáveis. A solução separa o texto original dos campos extraídos, classifica e georreferencia, mantém rastreabilidade e propõe o serviço competente sem transformar a sugestão do modelo numa decisão administrativa.

Hotelaria e comércio: horários e informação pública podem ser respondidos com baixa fricção; encomendas, alterações de estado e dados de hóspedes passam por validação, controlo de acesso e registo. A liberdade conversacional não se transforma em liberdade operacional.

O que ficou reutilizável

O principal resultado foi uma forma consistente de construir: inventário de ativos e dados, classificação de ações por impacto, fronteiras de confiança explícitas, recuperação autorizada, ferramentas pequenas, saída validada, intervenção humana e evidência operacional suficiente para investigar um erro. Estes padrões reduzem o trabalho de segurança em novos projetos sem presumir que dois setores têm o mesmo risco.

Segurança by design não significa prometer risco zero. Significa saber o que o sistema pode fazer, reduzir o raio de impacto quando falha e conseguir reconstruir o que aconteceu. Num agente de IA, essa honestidade arquitetural vale mais do que um prompt que promete obedecer.

Perguntas frequentes

Porque é que um agente de IA não deve ser tratado como uma aplicação tradicional?

Porque interpreta linguagem não confiável e produz resultados probabilísticos. Uma instrução pode chegar misturada com documentos, emails ou páginas externas. Por isso, o modelo não recebe autoridade direta: autenticação, autorização, validação e execução ficam em componentes determinísticos fora do modelo.

Como se protege um agente contra prompt injection?

Separam-se instruções do sistema, dados do utilizador e conteúdo recuperado; marca-se conteúdo externo como não confiável; limita-se o conjunto de ferramentas; validam-se parâmetros antes da execução; e exige-se confirmação humana nas ações de maior impacto. Um filtro de texto, sozinho, não é uma fronteira de segurança.

Um sistema RAG impede alucinações?

Não. O RAG melhora a fundamentação, mas não transforma o modelo numa base de dados determinística. É necessário controlar as fontes, aplicar permissões antes da recuperação, apresentar proveniência e impedir que uma resposta não suportada execute automaticamente uma ação de negócio.

O modelo de IA pode aceder diretamente aos sistemas da empresa?

Não deve. O modelo propõe uma intenção estruturada; uma camada de orquestração valida o esquema, a identidade, a autorização e os limites de cada operação. Só depois uma função com privilégios mínimos executa a ação permitida.

Que informação deve ficar nos logs de uma solução de IA?

Identificador de correlação, versão do fluxo e das instruções, fontes consultadas, ferramentas pedidas, decisão de autorização, tempos, erros e passagem para humano. Dados pessoais e conteúdo integral das conversas só devem ser registados quando existe finalidade e prazo de conservação definidos.

A supervisão humana é sempre necessária?

O nível depende do risco. Uma resposta sobre horários pode ser automática; uma denúncia, decisão com efeitos numa pessoa, alteração financeira ou escrita num sistema crítico exige controlo adicional, confirmação ou decisão humana. A arquitetura deve tornar essa fronteira explícita.

Quem desenvolveu estes padrões

A BigLearn é uma empresa portuguesa de consultoria em inteligência artificial, fundada em 2017 e sediada em Lisboa.

Este caso reúne decisões de arquitetura aplicadas em vários projetos e provas de conceito. Não representa uma única implantação nem atribui a um cliente controlos usados noutro. A tipificação é deliberadamente transversal e os clientes permanecem anonimizados.

Os outros casos de estudo descrevem os processos de negócio em que alguns destes padrões foram aplicados.

Outros casos de estudo

Turismo, Hotelaria e HORECA