A inteligência artificial já consegue escrever código, classificar informações, resumir documentos, detectar padrões e até tomar decisões com base em grandes volumes de dados.

Em uma aplicação PHP, isso abre muitas possibilidades.

Podemos usar IA para interpretar textos, sugerir respostas, categorizar chamados, identificar possíveis fraudes, analisar documentos ou até ajudar usuários a executar determinadas tarefas.

O problema começa quando colocamos a IA no papel de autoridade final do sistema.

Uma coisa é a IA sugerir uma ação.

Outra, completamente diferente, é permitir que ela decida sozinha se aquela ação pode ou não acontecer.

Essa diferença é importante porque modelos de IA trabalham com probabilidades. Aplicações de negócio, por outro lado, frequentemente precisam trabalhar com regras, permissões, consistência e rastreabilidade.

Neste artigo, vou mostrar alguns tipos de decisão que, na minha visão de desenvolvimento, não deveriam ser delegados exclusivamente a uma IA em uma aplicação PHP.

1. Quem pode acessar o quê

Uma das decisões que uma IA não deveria tomar sozinha é:

“Este usuário pode acessar este recurso?”

Autorização deve ser baseada em regras explícitas da aplicação.

Por exemplo:

if (!$user->hasPermission('financeiro.visualizar')) {
    throw new AccessDeniedHttpException();
}

Uma IA pode ajudar a interpretar uma solicitação do usuário:

“Quero consultar os dados financeiros da filial de Picos.”

Mas não deveria ser ela quem decide:

“Esse usuário provavelmente pode acessar esses dados.”

A decisão de autorização precisa considerar informações verificáveis:

• identidade;
• perfil;
• permissões;
• escopo;
• organização;
• vínculo com o recurso;
• regras de negócio.

Um bom padrão

A IA pode transformar uma linguagem natural em uma intenção.

A aplicação decide se aquela intenção é permitida.

Usuário
   ↓
IA interpreta a solicitação
   ↓
Aplicação identifica a operação
   ↓
Regra de autorização
   ↓
Executa ou bloqueia

A IA interpreta.

O sistema autoriza.

2. Alterar permissões de usuários

É ainda mais perigoso permitir que uma IA altere permissões diretamente.

Imagine um administrador digitando:

“Dê acesso financeiro ao João.”

A IA poderia interpretar quem é João e qual seria o perfil desejado.

Mas a aplicação deveria validar explicitamente:

$allowedRoles = [
    'financeiro',
    'financeiro_gestor',
];

if (!in_array($requestedRole, $allowedRoles, true)) {
    throw new DomainException('Perfil inválido.');
}

Além disso, mudanças sensíveis deveriam possuir:

• autenticação;
• autorização;
• auditoria;
• identificação do responsável;
• possibilidade de rastrear a alteração.

A IA pode preparar a alteração.

Ela não deveria ser a autoridade que concede o privilégio.

3. Movimentações financeiras

Esse é provavelmente um dos exemplos mais claros.

Imagine um sistema que permite:

• criar pagamentos;
• cancelar cobranças;
• emitir reembolsos;
• transferir valores;
• alterar dados bancários;
• aprovar despesas.

Uma IA pode analisar uma solicitação:

“Reembolse a última cobrança do cliente.”

Mas o fluxo financeiro deveria continuar sendo controlado por regras determinísticas.

Por exemplo:

if ($payment->isRefunded()) {
    throw new DomainException('Pagamento já reembolsado.');
}

if (!$payment->canBeRefunded()) {
    throw new DomainException('Pagamento não pode ser reembolsado.');
}

A IA pode identificar qual pagamento o usuário provavelmente está mencionando.

Mas quem decide se o pagamento pode ser reembolsado é a regra de negócio.

4. Exclusão definitiva de dados

Excluir dados permanentemente é outra decisão que não deveria depender exclusivamente de um modelo.

Considere uma solicitação:

“Pode apagar os dados desse cliente.”

Uma IA pode entender qual cliente foi mencionado.

Mas ainda precisamos validar:

• quem está solicitando;
• se o usuário possui permissão;
• se os dados podem ser excluídos;
• se existe retenção obrigatória;
• se existem registros relacionados;
• se existe uma política de anonimização;
• se a exclusão precisa de confirmação adicional.

Um sistema seguro pode fazer:

IA
 ↓
Identifica o cliente
 ↓
Aplicação valida permissão
 ↓
Aplicação valida regras de retenção
 ↓
Aplicação solicita confirmação
 ↓
Aplicação executa exclusão

A IA não deveria simplesmente receber uma ferramenta como:

$tools = [
    'delete_customer'
];

e decidir sozinha quando executá-la.

5. Alterações irreversíveis

O problema não é apenas exclusão.

Qualquer operação difícil de desfazer merece cuidado especial.

Exemplos:

• encerramento de conta;
• cancelamento de contrato;
• fechamento financeiro;
• emissão definitiva de documento;
• baixa de estoque;
• publicação oficial;
• envio de comunicação em massa;
• alteração definitiva de dados.

Uma boa regra prática é:

Quanto maior o impacto e menor a reversibilidade, menor deve ser a autonomia da IA.

6. Alterar regras de negócio

Outro erro seria permitir que a própria IA “decida” quais regras de negócio devem ser aplicadas.

Imagine:

“Determine automaticamente o desconto de cada cliente.”

A IA pode sugerir um percentual.

Mas não deveria substituir regras como:

if ($customer->isPremium()) {
    $discount = 10;
}

por uma decisão probabilística sem limites.

Podemos até usar IA para recomendar:

{
    "suggested_discount": 8,
    "reason": "Cliente possui histórico de compras recorrentes."
}

Mas a aplicação pode impor:

$discount = min($suggestedDiscount, 10);

Nesse modelo, a IA sugere.

O sistema limita.

7. Decisões de segurança

Talvez esse seja um dos pontos mais importantes.

Uma IA pode ajudar a identificar comportamento suspeito, mas não deveria ser o único mecanismo responsável por decidir questões críticas de segurança.

Por exemplo:

• bloquear uma conta;
• liberar uma autenticação;
• redefinir senha;
• desativar MFA;
• liberar uma operação sensível;
• alterar credenciais;
• marcar uma transação como segura.

Imagine:

Login
 ↓
IA diz "parece ser o usuário"
 ↓
Acesso concedido

Isso seria um desenho extremamente frágil.

A aplicação deveria trabalhar com mecanismos tradicionais:

• autenticação;
• sessão;
• tokens;
• MFA;
• controle de acesso;
• rate limiting;
• políticas de senha;
• logs;
• validação de origem;
• regras de segurança.

A IA pode funcionar como uma camada adicional de análise.

Não como substituta dos controles de segurança.

8. Validar documentos oficiais

Um modelo pode ser excelente em interpretar texto.

Isso não significa que ele seja a autoridade final sobre a validade de um documento.

Por exemplo:

“Este documento está correto?”

A IA pode apontar:

• campos suspeitos;
• inconsistências;
• informações ausentes;
• divergências entre documentos.

Mas a aplicação deve verificar regras objetivas sempre que possível.

Se existe uma API oficial, assinatura digital, certificado ou mecanismo de validação, ele deve continuar sendo a fonte de verdade.

A IA pode atuar como uma camada de análise.

Não como autoridade documental.

9. Definir valores críticos

Outro cuidado importante é permitir que uma IA escolha valores diretamente relacionados ao negócio.

Exemplos:

• preço de produto;
• limite de crédito;
• valor de multa;
• comissão;
• taxa;
• orçamento;
• desconto máximo;
• valor de reembolso.

Uma IA pode sugerir:

{
    "price": 149.90,
    "confidence": 0.87
}

Mas isso não significa:

$product->setPrice($aiPrice);

sem nenhuma validação.

O sistema ainda precisa verificar:

if ($aiPrice <= 0) {
    throw new DomainException('Preço inválido.');
}

if ($aiPrice < $minimumPrice) {
    throw new DomainException('Preço abaixo do permitido.');
}

A IA pode participar da decisão.

Ela não precisa ser a responsável por encerrá-la.

10. Contratos e compromissos jurídicos

Operações que criam compromissos legais também exigem cuidado.

Por exemplo:

“Gere o contrato e envie para assinatura.”

A IA pode ajudar a gerar o conteúdo.

Mas a aplicação deve controlar:

• qual contrato foi selecionado;
• qual versão está sendo utilizada;
• quem possui autorização;
• quais dados foram inseridos;
• quais condições foram aceitas;
• quem aprovou;
• qual versão foi assinada.

O problema não é usar IA para gerar documentos.

O problema é transformar um texto gerado probabilisticamente em uma decisão oficial sem validações.

11. Alterar o banco de dados diretamente

Uma das práticas que mais merece atenção é permitir que um agente de IA execute SQL livremente em produção.

Por exemplo:

Usuário:
"Corrija o cadastro do cliente João."

IA:
UPDATE customers
SET status = 'active'
WHERE name = 'João';

Esse tipo de autonomia pode produzir erros difíceis de detectar.

Em sistemas críticos, é muito mais seguro expor operações controladas:

$customerService->activateCustomer($customerId);

em vez de oferecer:

executeSql($query);

Isso cria uma fronteira importante.

A IA não decide como o banco deve ser manipulado.

Ela chama operações explicitamente permitidas pela aplicação.

12. Alterar configurações de produção

Uma IA pode analisar logs e sugerir:

“O PHP-FPM está com poucos workers. Aumente pm.max_children.”

Excelente.

Mas permitir que o modelo execute automaticamente:

systemctl restart php8.2-fpm

ou altere arquivos de produção sem restrições é outra história.

Em ambientes críticos, existe uma diferença importante entre:

IA diagnostica

e:

IA executa alteração em produção

A primeira pode ser uma grande ajuda.

A segunda precisa de controles adicionais.

13. Aprovar deploys automaticamente

Ferramentas com IA podem analisar:

• pull requests;
• testes;
• logs;
• vulnerabilidades;
• alterações de código.

Mas isso não significa que a IA deveria ser a única responsável por decidir:

“Pode ir para produção.”

Um pipeline pode exigir:

Commit
 ↓
Testes automatizados
 ↓
Análise de segurança
 ↓
Análise por IA
 ↓
Review humano
 ↓
Deploy

A IA aumenta a capacidade do processo.

Não elimina necessariamente a necessidade de revisão.

14. Classificar usuários automaticamente em situações críticas

Classificações feitas por IA também precisam de cuidado.

Por exemplo:

• aprovar crédito;
• bloquear cliente;
• classificar fraude;
• negar acesso;
• definir nível de risco;
• priorizar atendimento.

Mesmo quando o modelo apresenta uma probabilidade:

{
    "fraud_probability": 0.92
}

isso não significa automaticamente:

$account->block();

O sistema precisa definir:

• quais sinais são considerados;
• quais limites existem;
• o que acontece com falsos positivos;
• se existe revisão humana;
• como recorrer da decisão;
• como registrar a justificativa.

15. O princípio que uso: IA sugere, aplicação decide

Uma arquitetura interessante para sistemas que utilizam IA é separar claramente responsabilidades.

Podemos pensar em três camadas:

┌─────────────────────────────┐
│             IA              │
│ interpretação / sugestão    │
└──────────────┬──────────────┘
               ↓
┌─────────────────────────────┐
│     Regras da aplicação     │
│ validação / autorização     │
└──────────────┬──────────────┘
               ↓
┌─────────────────────────────┐
│        Execução             │
│ banco / API / negócio       │
└─────────────────────────────┘

A IA pode ser excelente em tarefas como:

• interpretar linguagem natural;
• resumir;
• classificar;
• sugerir;
• detectar padrões;
• gerar conteúdo;
• transformar dados;
• extrair informações.

Já a aplicação deve continuar responsável por:

• autenticação;
• autorização;
• validação;
• regras de negócio;
• integridade;
• limites;
• transações;
• persistência;
• auditoria.

Essa separação torna o comportamento do sistema muito mais previsível.

Um exemplo prático em PHP

Imagine um assistente que recebe:

“Cancele o pedido 54321.”

A IA pode retornar algo estruturado:

{
    "intent": "cancel_order",
    "order_id": 54321
}

Isso é muito melhor do que deixar a IA executar diretamente alguma ação.

O PHP pode receber a intenção:

$command = $ai->interpret($message);

E então aplicar as regras:

if ($command->intent === 'cancel_order') {
    $order = $orderRepository->find($command->orderId);

    if (!$order) {
        throw new NotFoundException();
    }

    if (!$currentUser->canCancel($order)) {
        throw new AccessDeniedHttpException();
    }

    if (!$order->canBeCancelled()) {
        throw new DomainException(
            'O pedido não pode mais ser cancelado.'
        );
    }

    $orderService->cancel($order);
}

Aqui existe uma divisão muito mais segura:

IA:

“Acredito que o usuário quer cancelar o pedido 54321.”

Aplicação:

“Vou verificar se ele pode fazer isso.”

Essa é uma diferença arquitetural importante.

Use IA como copiloto, não como autoridade

Uma aplicação preparada para IA não precisa rejeitar a automação.

O objetivo não é limitar a IA artificialmente.

É colocar a IA no lugar correto da arquitetura.

Ela pode ser extremamente poderosa para:

• interpretar solicitações;
• acelerar operações;
• sugerir decisões;
• encontrar anomalias;
• analisar grandes volumes de dados;
• ajudar desenvolvedores;
• melhorar a experiência do usuário.

Mas determinadas decisões devem continuar protegidas por regras determinísticas.

Principalmente quando envolvem:

dinheiro, acesso, segurança, dados sensíveis, exclusão, contratos, permissões ou operações irreversíveis.

Uma regra simples pode ajudar durante o desenvolvimento:

Se uma decisão pode causar um impacto importante e não existe uma maneira simples de desfazer o resultado, a IA não deveria ser a única autoridade sobre essa decisão.

Checklist rápido

Antes de permitir que uma IA execute uma ação diretamente em uma aplicação PHP, vale perguntar:

• Essa ação envolve dinheiro?
• Altera permissões?
• Afeta segurança?
• Exclui dados?
• É difícil de desfazer?
• Altera uma regra de negócio?
• Envolve dados sensíveis?
• Pode gerar um compromisso legal?
• Pode impactar vários usuários?
• Existe uma validação determinística possível?
• Existe auditoria?
• Existe limite para a ação?
• Existe rollback?
• Existe revisão humana quando necessário?

Quanto mais respostas forem “sim”, maior deve ser o controle sobre a autonomia da IA.

Conclusão

A discussão sobre IA no desenvolvimento não deveria ser apenas:

“O que a IA consegue fazer?”

Uma pergunta igualmente importante é:

“O que a IA deveria estar autorizada a fazer?”

Em uma aplicação PHP, colocar IA em um fluxo não significa entregar a ela o controle completo do processo.

Uma arquitetura mais segura é aquela em que a IA interpreta, analisa e sugere, enquanto o sistema continua responsável por validar, autorizar e executar.

No fim, não é necessário escolher entre automação e controle.

Podemos ter os dois.

A IA pode ser o copiloto.

Mas as regras da aplicação continuam no comando.