Arthur Guttilla Head of Product Marketing, Strattum Com passagens na Amazon Web Services e no Google, Guttilla trabalhou diretamente com fundadores de startups e empresas de capital de risco, compreendendo as necessidades de empresas tecnológicas em estágio inicial na interseção entre tecnologia e negócios.
TL;DR: Citação de origem e trilha de auditoria precisam ser produzidas pelo componente que recupera o dado, e não pela interface que exibe a resposta. Controles implementados na camada de apresentação deixam de valer quando agentes, automações e integrações passam a consumir a plataforma por API, que é exatamente o momento em que o volume de consultas cresce.
A primeira aplicação normalmente tem interface própria. Nela, é fácil montar um painel lateral com as fontes e registrar a consulta no backend da própria aplicação.
Seis meses depois, três consumidores novos aparecem: um agente que roda em batch, uma automação disparada por webhook e uma integração com a ferramenta de atendimento. Nenhum passa pela interface.
Se a citação e o log viviam ali, esses três consumidores operam sem rastreabilidade. E eles costumam gerar mais consultas do que a interface original.
Cada chamada de recuperação deveria devolver, junto com o conteúdo:
Com esse envelope, qualquer consumidor exibe ou registra o que precisar. A interface decide a apresentação e não é responsável por gerar a informação.
Além do que volta para o consumidor, a camada registra a consulta completa:
| Campo | Uso |
|---|---|
| Identidade do usuário ou do agente | Investigação e revisão de permissão |
| Pergunta ou parâmetros recebidos | Distinguir uso legítimo de contorno |
| Trechos recuperados | Reconstruir o que alimentou a resposta |
| Filtros de permissão aplicados | Provar que a restrição foi executada |
| Modelo e versão, quando informado | Explicar mudança de comportamento |
| Latência e volume enviado | Diagnóstico de custo e desempenho |
Os dois últimos campos servem também para operação, o que ajuda a justificar o esforço de instrumentação para times que veem auditoria como custo.
Uma resposta de recuperação bem desenhada separa conteúdo de procedência, para que o consumidor decida o que fazer com cada parte:
{
"trechos": [
{
"conteudo": "...",
"origem": {
"sistema": "erp",
"registro": "fatura:2026-0041982",
"data_do_dado": "2026-08-31",
"versao": null
},
"recuperado_por": "consulta_estruturada",
"filtros_aplicados": ["permissao:usuario_1187", "cliente:8842"]
}
],
"consulta_id": "c_9f31a2",
"fontes_consultadas": ["erp", "crm"],
"fontes_indisponiveis": []
}O campo de fontes indisponíveis merece atenção. Sem ele, uma fonte fora do ar produz resposta silenciosamente incompleta, que é o pior modo de falha possível em ambiente corporativo.
Três razões técnicas.
O envelope muda o contrato. Acrescentar metadado de origem altera a resposta da API e obriga a ajustar todos os consumidores existentes.
O histórico não é reconstituível. Consultas passadas não geram log retroativo, então a auditoria começa do zero na data da mudança.
A permissão retroativa é ainda pior. Se o filtro nunca foi aplicado na recuperação, não há registro de quem alcançou o quê, e o levantamento de impacto precisa ser feito por inferência.
Uma empresa de logística construiu o primeiro assistente com painel de fontes na interface web. Funcionava bem e o time de segurança aprovou.
Seis meses depois, um agente automatizado passou a gerar relatórios diários consumindo a mesma base por API, e a operação de atendimento integrou a plataforma ao sistema de tickets.
Na auditoria seguinte, a empresa conseguiu demonstrar rastreabilidade de 18% das consultas, que era a fatia originada na interface. O trabalho de mover citação e log para a camada de recuperação levou dois meses e exigiu versionar a API para não quebrar os consumidores existentes.
O mesmo registro que atende auditoria resolve o problema operacional mais comum, que é investigar uma resposta ruim.
Com os trechos recuperados guardados, a análise leva minutos: ou o material correto não foi recuperado, e o problema está na busca, ou ele estava lá e o modelo não o usou, e o problema está no prompt ou no modelo.
Sem esse registro, a investigação vira tentativa de reproduzir a consulta, com o agravante de que o estado das fontes já mudou.
A ordem que gera menos ruptura tem quatro passos.
O passo 2 é o que mais rende no curto prazo, porque o registro passa a existir sem depender da migração de ninguém.
É por isso que, em um Company Brain, citação de origem e log nascem na recuperação e não na tela.
Acopla intencionalmente. O acoplamento evita que cada consumidor implemente a própria versão parcial do controle.
O envelope é para o consumidor. O que vai ao modelo pode ser apenas o conteúdo, com as referências mantidas do lado da aplicação para compor a resposta final.
Vale registrar todas, com política de retenção diferenciada por criticidade, em vez de decidir caso a caso o que registrar.
Fale com um especialista da Strattum sobre onde a sua plataforma hoje gera fonte e log, e o que muda ao mover isso para a recuperação.