Uma resposta de IA pode parecer precisa e, ainda assim, ser inadequada para operar sobre um sistema. O facto de classificar um pedido como urgente, sugerir o preenchimento de um campo ou recomendar o início de um fluxo não significa que tenha autorização, contexto suficiente ou que cumpra as regras de negócio. O risco surge quando uma sugestão textual ou estruturada é transformada numa ordem executável sem barreiras independentes.
Para validar saídas estruturadas de IA em PHP, convém tratar o modelo como um componente que prepara propostas, e não como uma autoridade que modifica registos, atribui responsáveis, envia comunicações ou inicia processos. A aplicação mantém a decisão, aplica as suas próprias regras e regista o motivo pelo qual uma proposta foi aceite, corrigida ou rejeitada.
Uma saída plausível não é uma instrução válida
Os modelos podem devolver JSON sintaticamente correto e, ainda assim, incluir uma prioridade inexistente, um identificador que não corresponde ao cliente, uma data impossível ou uma ação que o utilizador não pode solicitar. Também podem preencher dados que não estão presentes na entrada, interpretar mal uma ambiguidade ou seguir um formato antigo após uma alteração do contrato.
O limite operacional deve ser explícito: a IA pode propor uma ação e explicar os dados que usou; o sistema decide se essa proposta passa a ser um rascunho, requer revisão ou pode ser executada em condições muito delimitadas. Esta separação protege tanto a integridade dos dados como a responsabilidade pela decisão.
Um bom ponto de partida é classificar cada ação por impacto:
- Baixo impacto: etiquetar um rascunho, sugerir uma categoria ou extrair campos não críticos.
- Impacto médio: criar uma tarefa pendente, propor um responsável ou preparar uma resposta para revisão.
- Alto impacto: alterar estados contratuais, atribuir trabalho irreversível, modificar montantes, eliminar dados, comunicar externamente ou ativar processos sensíveis.
A autonomia admissível não depende de a IA ter uma confiança declarada elevada. Depende da reversibilidade, do custo de um erro, da qualidade verificável dos dados e da existência de controlos fora do modelo.
Definir um contrato de proposta antes de integrar o modelo
O contrato de saída define o que o componente de IA pode propor e o que fica fora do seu âmbito. Deve ser pequeno, tipado e versionado. Em vez de pedir “decide o que fazer com este pedido”, especifique uma lista fechada de ações e os campos necessários para cada uma.
{
"version": "1",
"action": "create_task_draft",
"category": "billing",
"priority": "normal",
"summary": "Rever discrepância na fatura",
"sourceReferences": ["message:123"],
"confidence": 0.82
}A lista de ações deve utilizar valores controlados, por exemplo create_task_draft, request_more_information ou no_action. Não convém aceitar nomes de métodos, consultas, fragmentos de código, destinatários livres nem instruções do tipo “atualiza a encomenda”. A aplicação traduz uma ação permitida numa operação interna concreta.
Campos, estados e evidência
Além de tipos e valores permitidos, o contrato deve indicar quais os campos obrigatórios, quais as combinações incompatíveis e que evidência a proposta deve fornecer. Uma categoria pode ser válida, mas exigir pelo menos uma referência à mensagem ou ao documento de origem. A confiança, se for recolhida, é um dado auxiliar para ordenar revisões; não substitui uma validação.
Versionar o esquema permite rejeitar com segurança saídas de contratos retirados. Se uma alteração adicionar um campo obrigatório ou retirar uma ação, o adaptador deve reconhecer a versão e evitar interpretações implícitas.
Aplicar quatro barreiras antes de qualquer efeito
A validação deve ocorrer em camadas separadas. Uma falha numa camada não é compensada por uma resposta aparentemente razoável noutra.
- Formato: verificar que a resposta pode ser descodificada, que respeita o esquema esperado, que não contém campos críticos inesperados e que cada valor tem o tipo correto. Um JSON inválido, uma enumeração desconhecida ou um campo obrigatório em falta são rejeitados.
- Domínio: verificar regras próprias da aplicação. Por exemplo, que a categoria existe, que a prioridade é aplicável ao tipo de pedido, que a conta referida está habilitada e que a referência de origem pertence ao contexto processado.
- Autorização: verificar o que o ator que iniciou o fluxo pode fazer e que permissões a operação exige. A IA não herda privilégios ilimitados nem decide o âmbito de acesso. O servidor aplica a identidade, o tenant e as políticas em vigor.
- Condições operacionais: rever concorrência, estados atuais, limites, dependências e idempotência. Uma proposta válida pode não poder ser executada se o caso já tiver sido fechado, se outro processo tiver alterado o registo ou se tiver sido excedido um limiar de carga.
A validação semântica deve consultar fontes de verdade internas. Não basta que o modelo devolva um identificador bem formado: o repositório ou serviço de domínio deve verificar a sua existência, pertença e estado. Evite que a resposta do modelo transporte dados de autorização que a aplicação pode resolver por si própria.
Arquitetura PHP: proposta, decisão e execução separadas
Uma arquitetura sustentável separa responsabilidades. O adaptador de IA prepara o pedido, aplica limites de tamanho e obtém uma saída; não escreve na base de dados de negócio. Um DTO representa a proposta já parseada. O validador de domínio transforma essa proposta numa decisão com erros explícitos. Por fim, um executor autorizado aplica apenas decisões aprovadas.
final class ActionProposal {
public function __construct(
public string $action,
public string $category,
public string $priority,
public array $sourceReferences,
) {}
}
$proposal = $aiAdapter->propose($input);
$validation = $domainValidator->validate($proposal, $context);
if (!$validation->isApproved()) {
$auditLog->recordRejected($proposal, $validation->reasons());
return $validation;
}
return $decisionService->route($validation->approvedProposal(), $context);O serviço de decisão pode criar um rascunho, colocá-lo numa fila de revisão ou solicitar aprovação humana. O executor final deve receber um objeto de decisão interno, e não a resposta bruta nem o JSON da IA. Assim, evita-se que uma extensão acidental do contrato se transforme numa nova capacidade operacional.
Utilize transações para alterações relacionadas, chaves de idempotência para novas tentativas e controlos de concorrência quando várias pessoas ou processos puderem atuar sobre o mesmo caso. Diferencie também implementação de ativação: o código pode estar implementado sem expor o fluxo a utilizadores reais. Uma ativação gradual permite observar rejeições, tempos e correções antes de ampliar o âmbito.
Escolher revisão humana, automatização limitada ou rejeição
A revisão humana é adequada quando existem ambiguidades materiais, dados sensíveis, consequências externas, exceções de política ou custos elevados de correção. A interface de revisão deve mostrar a proposta, a evidência de origem permitida, as regras superadas e os motivos de alerta, sem apresentar a recomendação como um facto.
A automatização limitada pode ser razoável para operações reversíveis e delimitadas: criar um rascunho sem responsável atribuído, aplicar uma etiqueta provisória ou encaminhar um pedido para uma fila geral. Deve ter limites de frequência, possibilidade de desfazer e supervisão posterior. Se faltarem dados, houver conflito entre regras ou a ação estiver fora da lista permitida, o comportamento seguro é rejeitar ou escalar, não improvisar.
Antes de utilizar IA, avalie uma alternativa determinística. Se as entradas seguirem padrões estáveis, regras, formulários guiados, listas de seleção ou um classificador convencional podem ser mais baratos, auditáveis e previsíveis. Quando utilizar IA, defina o caso de uso, um conjunto de avaliação representativo, limiares operacionais, custo por volume e um modo de degradação caso o fornecedor falhe ou exceda o tempo esperado.
Exemplo: converter um pedido num rascunho de tarefa
Suponha um pedido recebido que menciona uma discrepância numa fatura. A IA pode propor a categoria billing, prioridade normal e o resumo de uma tarefa. O validador verifica que a mensagem pertence ao tenant atual, que a categoria está disponível e que ainda não existe um caso aberto com a mesma referência. Se tudo estiver correto, o sistema cria um rascunho sem atribuir um responsável nem modificar o estado da fatura.
Um operador revê o rascunho, confirma ou corrige a categoria e decide a atribuição de acordo com a carga e as permissões em vigor. Esta distinção impede que uma inferência plausível sobre um responsável ou um montante se transforme numa alteração incorreta. Se o contrato exigir um número de fatura e este não aparecer na mensagem, a proposta deve solicitar informações adicionais, não inventá-lo.
Rastreabilidade, privacidade e testes antes de ampliar o fluxo
Registe um identificador de correlação, a versão do contrato, a impressão digital ou referência da entrada minimizada, a proposta normalizada, os resultados de cada validação, a decisão final, o ator aprovador quando exista e o motivo de rejeição. O registo deve ser útil para investigar incidentes sem duplicar dados pessoais ou conteúdo sensível desnecessário. Aplique retenção, acesso restrito e técnicas de minimização adequadas ao risco do processo.
Teste o fluxo com casos representativos e adversos: entradas incompletas, instruções contraditórias, valores inventados, referências de outro tenant, alterações de estado concorrentes, respostas com formato antigo, latência e ausência do serviço de IA. Os critérios de aceitação devem medir se as operações não autorizadas são bloqueadas, se os rascunhos são recuperáveis, se as rejeições são compreensíveis e se o sistema mantém uma alternativa funcional perante falhas.
A operação segura não consiste em conseguir que o modelo responda sempre. Consiste em garantir que, quando responder mal, demorar demasiado ou não responder, a aplicação PHP mantém o controlo e não produz efeitos que não possa justificar.
