A reunião técnica está marcada pra escolher como o agente de IA vai conversar com o ERP da empresa. Na pauta: sidecar via API gateway, webhook com fila assíncrona, change data capture sobre o banco. Os três aparecem em qualquer comparativo de integração com sistema legado. O comitê discute latência, custo de mudança no legado, complexidade de implantação. E nenhum dos engenheiros na sala faz a pergunta que vem antes de todas as outras: esse agente vai apenas ler o estado do legado, ou também alterar estado?
Não é detalhe semântico. É a decisão que define o perfil de risco do projeto antes de qualquer padrão arquitetônico. Erro de chatbot é resposta errada — alguém relê e segue a vida. Erro de agente que escreve no legado é pedido errado disparado, status alterado em registro que não devia, transação iniciada sem autorização. A Atlan, no relatório de guardrails 2026, fecha a distinção em uma frase: "quando um chatbot alucina, você recebe uma resposta errada; quando um agente alucina, o resultado pode ser transação não-autorizada, perda de dado ou decisão incorreta". A pesquisa McKinsey citada no mesmo material registra que cerca de oitenta por cento das organizações já encontraram comportamento de agente considerado arriscado, incluindo exposição não-autorizada de dado e acesso impróprio a sistema.
A pergunta read-only ou read-write não substitui a escolha do padrão de integração. Ela vem antes — e reorganiza todas as outras decisões.
Principais pontos
- Read-only e read-write são perfis de IA distintos, não duas configurações da mesma arquitetura — risco, governança, auditoria e padrão de aprovação humana mudam radicalmente entre os dois.
- CDC (change data capture) só serve a perfil read-only, porque é unidirecional por desenho — descobrir isso na arquitetura é caro; descobrir na decisão é grátis.
- Sidecar e webhook suportam ambos, mas a topologia de aprovação humana muda — read-only roda autônomo; read-write exige porta de aprovação pra operação de risco.
- Princípio do menor privilégio aplica a tools, não só a credenciais — o agente que só consulta saldo não deveria ter ferramenta de transferência registrada na sua API de ações.
- Governança nativa vem desenhada desde o primeiro diagrama, não adicionada depois — Gartner projeta que, até 2030, cerca de metade das falhas de deploy de agente virá de gaps de governança e interoperabilidade quebrada.
- Estratégia progressiva (read-only → read-write controlado) reduz a janela de risco, e dá tempo pra operação aprender padrões de comportamento antes de delegar ação ao agente.
Por que o decisor B2B precisa entrar nessa pergunta
Pra clientes médios discutindo com parceiros como a Vertis Tech o desenho de um agente de IA sobre sistema interno em produção, o CTO ou dono da operação geralmente chega à reunião com uma pergunta de mercado: "qual é a melhor arquitetura pra plugar IA no nosso ERP?". Esse fraseado já assume que arquitetura é a primeira decisão. Não é. Antes disso vem o perfil da IA — e o decisor é quem responde, porque a resposta não é técnica, é de tolerância a risco operacional. Quem decide o que o agente pode mexer dentro do sistema da empresa não é o engenheiro de integração. É quem responde pela operação quando algo dá errado.
Read-only: o agente que observa e responde
O agente read-only lê estado do legado e usa esse contexto pra responder, classificar, recomendar ou gerar conteúdo. Ele não altera nada. Em ERP, isso é o agente que responde "qual o status do pedido 4231?" consultando o registro e formatando a resposta. Em CRM, é o agente que prioriza leads quentes lendo histórico de interação. Em sistema fiscal, é o agente que classifica documento entrando, comparando com base histórica.
O perfil read-only tem características de risco específicas:
- A pior falha possível é dado pessoal exposto a quem não devia ver — risco LGPD, não risco operacional. O legado não é alterado.
- A auditoria foca em controle de acesso e logging de consulta, não em rastreamento de transação.
- Aprovação humana é geralmente opcional, na maioria dos fluxos síncronos.
- CDC funciona muito bem, porque o caso de uso é exatamente "ter o estado do legado disponível pra leitura sem perguntar".
- Sidecar e webhook também funcionam, mas adicionam camada que não é necessária — o legado não precisa ser notificado de nada porque ninguém vai escrever.
A decisão de arquitetura pra read-only termina em "qual é a forma menos invasiva de manter o agente com leitura atualizada do estado?". CDC sobre o banco do legado, sem tocar no código antigo, costuma vencer em projetos onde o time mantenedor do sistema antigo não vai abrir endpoint novo.
Read-write: o agente que altera estado
O agente read-write age sobre o legado. Cria registro, atualiza status, dispara workflow, finaliza transação. Em ERP, é o agente que abre OS no sistema antigo. Em CRM, é o agente que move card no funil ou atualiza tag em contato. Em sistema fiscal, é o agente que emite documento ou registra movimentação.
O perfil read-write tem outro mundo de risco:
- A pior falha possível é estado corrompido em sistema em produção — registro criado errado, transação disparada sem autorização, status revertido sem rastro do gatilho que motivou.
- A auditoria precisa cobrir cada ação, com correlação clara entre o input que motivou e o estado final. O Atlan documenta um padrão de incidente que apareceu em 2026: time de segurança descobre que agente esteve escrevendo em sistema de produção ao longo de um fim de semana inteiro, com logs registrando cada ação — mas nenhum alerta disparou porque não havia regra de detecção pra comportamento iniciado por agente.
- Aprovação humana deixa de ser opcional pra operações de risco — emissão de documento fiscal, alteração de status que dispara cobrança, finalização de venda.
- CDC sai da mesa, porque é unidirecional. O agente precisa de canal próprio de escrita.
- Sidecar via API gateway vence quando o legado expõe endpoint estável, porque a escrita fica síncrona e o retorno do legado (sucesso ou erro) pode ser tratado na hora.
- Webhook com fila ganha quando o legado é instável ou indisponível em janelas, porque preserva a ordem de operações e permite retry com cuidado.
A decisão de arquitetura pra read-write não é "menos invasivo possível" — é "mais auditável e reversível possível dentro da latência aceitável".
Por que essa distinção reorganiza a conversa com o fornecedor
Quando o fornecedor de IA chega com proposta única — "vamos implementar o agente com webhook assíncrono" — sem antes propor o gradiente read-only versus read-write, é sinal de imaturidade na conversa. O perfil de operação do cliente decide o que cabe e o que não cabe:
- Operação com baixa maturidade de auditoria começa read-only. Período. O ganho operacional de ter IA respondendo, classificando e priorizando geralmente cobre o caso de negócio inicial, e dá tempo de construir telemetria e regra de detecção antes de soltar escrita.
- Operação que precisa de IA executora desde o início entra read-write, mas com tópico inteiro de discussão sobre quais ações exigem aprovação humana, como o rollback funciona e qual time recebe alerta quando ação suspeita ocorre.
- Operação que mistura os dois perfis (típico — agente lê histórico do cliente, classifica, e em alguns casos atualiza tag no CRM) precisa de separação clara de tools no nível da API do agente: a ferramenta de leitura é uma, a ferramenta de escrita é outra, e o nível de aprovação é definido por ferramenta, não por sessão.
A Gartner projeta que cerca de metade das falhas de deploy de agente de IA até 2030 virá de gaps de governança e interoperabilidade quebrada. A maioria dessas falhas começa exatamente aqui — no momento em que o comitê escolhe arquitetura antes de escolher perfil, e descobre depois que o padrão escolhido não suporta a governança que precisaria existir.
O princípio do menor privilégio aplicado a tools
Em segurança clássica, menor privilégio significa que credencial só vê o que precisa ver. Em agente de IA, o conceito muda de lugar — vai pra registro de tools. O agente que só consulta saldo não deveria ter ferramenta de transferência registrada na sua API de ações, mesmo que a credencial do legado teoricamente permita ambas. Porque o que define se o LLM vai chamar a operação não é a credencial — é a presença da ferramenta no menu de ações disponíveis.
Isso muda como o fornecedor desenha o adapter pro legado. Não é "um wrapper genérico do legado pra usar dentro do agente". É um conjunto curado de operações, com escopo definido por caso de uso. Operações de escrita ganham porta de aprovação humana configurada por regra de risco; operações de leitura passam direto. Adicionar tool no agente é decisão de produto e de governança — não é configuração interna de implantação.
Estratégia progressiva: read-only primeiro
Pra projeto novo, o desenho que costuma reduzir mais a janela de risco é começar read-only e expandir pra read-write em ciclos controlados. O ganho operacional já aparece na primeira fase — agente respondendo, classificando, recomendando — com risco contido a controle de acesso e LGPD. Enquanto isso, o time interno desenvolve o que precisa estar pronto antes de soltar escrita:
- Telemetria por ação de agente — quem chamou, com que input, que tool foi acionada, qual foi o output, em que momento.
- Regras de detecção pra comportamento iniciado por agente — pra que alerta dispare quando ação inesperada ocorre, fim de semana ou não.
- Catálogo de operações elegíveis pra escrita, com classificação de risco — quais exigem aprovação humana, quais podem rodar autônomas em janela controlada, quais não entram nem com aprovação.
- Rollback testado — toda operação de escrita precisa ter caminho de reversão validado em homologação antes de subir pra produção.
Quando read-write entra, o time já sabe o que está olhando e como reagir. Isso é diferente de plugar tudo de uma vez e descobrir o problema na produção.
Como a Vertis Tech ajuda em IA sobre sistema legado
A Vertis Tech é fábrica de software brasileira focada em CRM, automação e IA aplicada. Cada projeto de IA acoplada a sistema existente é dimensionado conforme a sensibilidade dos dados do legado, o perfil de operação que a IA vai assumir (leitura vs. escrita), a maturidade de auditoria do cliente e a topologia do sistema antigo. A depender do escopo, a implantação pode contemplar:
- Discovery do perfil read-only vs read-write antes da escolha do padrão arquitetônico, pra que o cliente saiba o que está contratando em termos de risco — não só em termos de feature.
- Catálogo curado de tools por caso de uso, no lugar de adapter genérico do legado — operações de leitura e escrita separadas no nível da API do agente, com escopo definido por ferramenta.
- Camada de aprovação humana configurada por regra de risco pra ações de escrita em produção, com auditoria append-only e correlação entre input do agente, decisão de tool e estado final no legado.
- Telemetria por ação de agente desde o primeiro deploy, integrada à observabilidade interna do cliente — pra que alertas disparem quando comportamento atípico ocorre, inclusive em janelas fora do horário comercial.
- Estratégia progressiva read-only → read-write quando o caso permite, pra reduzir janela de risco e dar tempo do time interno construir resposta operacional antes de delegar ação.
- Governança LGPD desenhada desde o primeiro diagrama, com definição contratual de papéis (controlador, operador, subprocessadores), classificação de dado pessoal por tool e rastreabilidade de acesso a cada consulta ou ação.
Perguntas frequentes
O agente read-only é seguro o suficiente pra rodar sem aprovação humana?
Depende de o que ele acessa. Se o agente lê só dado público ou agregado, geralmente sim. Se lê dado pessoal de cliente final, mesmo sem alterar nada, a operação ainda recai em LGPD — controle de acesso, logging de consulta e definição de finalidade ficam obrigatórios. Aprovação humana caso a caso costuma ser desnecessária, mas a auditoria não.
Posso começar read-write e restringir depois?
Em teoria, sim. Na prática, raramente é o caminho que reduz risco. Começar read-write significa que time, processo, telemetria e regra de detecção precisam estar prontos no dia um — porque qualquer atraso vira janela de exposição. Começar read-only e expandir em ciclos costuma ser mais barato em incidente evitado, mesmo que pareça mais lento na linha do tempo do projeto.
Como saber se o fornecedor está pensando nessa distinção?
Pergunte na proposta como ele vai separar tools de leitura e tools de escrita na arquitetura do agente, e como a aprovação humana entra na sequência de execução de cada ação de risco. Se a resposta for "depois a gente configura" ou "isso é detalhe de implantação", o fornecedor está vendendo arquitetura sem pensar em governança. Se for "esse desenho depende de o que vocês consideram ação de risco e qual é a maturidade da telemetria interna", o fornecedor está fazendo a pergunta certa.
CDC sobre o banco do legado não é arriscado por si só?
O risco está mais em "quem tem acesso ao tópico de eventos do CDC" do que no CDC em si. CDC é unidirecional e não altera o legado — o time que mantém o sistema antigo nem precisa saber que existe (e geralmente nem deveria depender disso). O risco aparece quando o tópico de eventos vaza dado pessoal pra consumidor que não devia ter acesso. Controle de acesso ao stream resolve a maior parte dos casos.
E quando o legado não expõe API e o time mantenedor não vai abrir nada?
Esse é o caso ideal de CDC pra perfil read-only — você lê do banco do legado sem pedir nada pro time mantenedor. Pra read-write sem API, fica difícil. Sidecar com endpoint específico exposto pelo time interno, ainda que mínimo, costuma ser o caminho menos arriscado — porque mantém o ponto de escrita controlado e auditável. Webhook só funciona se o legado tiver mecanismo de receber chamada externa, o que geralmente exige aprovação do time mantenedor de qualquer forma.
Fechamento
A pergunta "read-only ou read-write" parece simples até a operação real começar. Comitês que decidem arquitetura antes de definir perfil descobrem, semanas depois, que escolheram padrão que não suporta a governança que a operação exige. Comitês que invertem a sequência — perfil primeiro, arquitetura segundo — tendem a pagar menos retrabalho e a dormir melhor enquanto a IA roda. A diferença está em quem faz a pergunta antes da reunião técnica, não dentro dela.
