PulseFlow Tecnologia
← Insights
·6 min de leitura·guia-tecnico·rag·mcp·shadow-ai
PulseFlow Tecnologia

Como usar RAG, MCP e ferramentas externas sem criar Shadow AI

Shadow AI não nasce de má intenção - nasce de times resolvendo, cada um à sua maneira, o mesmo problema: como conectar um agente a dados corporativos e a informação externa atual. Quando cada time monta seu próprio pipeline de RAG e sua própria integração MCP sem coordenação, o resultado é exatamente Shadow AI: acesso a dado sensível sem inventário central, sem política de retenção, sem log auditável. A AWS resolveu essa mesma dor com dois lançamentos que servem de referência de arquitetura, mesmo para quem não usa AWS.

Inventário de fontes: o problema que o Managed Knowledge Base ataca primeiro

Antes de qualquer política de segurança, é preciso saber o que existe. O Managed Knowledge Base da AWS resolve isso com seis conectores nativos pré-construídos - Amazon S3, SharePoint, Confluence, Web Crawler, Google Drive, OneDrive - centralizando conexão a fontes de dados corporativas num só lugar gerenciado, em vez de cada time escrever seu próprio conector. Esse é o primeiro passo prático contra Shadow AI: se toda fonte de dado passa por um inventário central, não existe conector "invisível" criado por um time isolado.

RAG governado: parsing e chunking centralizados, não artesanais

O recurso de "Smart Parsing" escolhe automaticamente a estratégia de chunking por tipo de conteúdo, com processamento multimodal. Isso pode parecer um detalhe técnico, mas tem implicação direta de governança: quando cada time decide sozinho como fragmentar e indexar dado sensível, a política de acesso granular vira impossível de auditar de forma consistente. Um pipeline de RAG centralizado, com regras de chunking padronizadas, é o que permite aplicar a mesma política de escopo de acesso a qualquer fonte nova.

MCP governado: retrieval multihop com rastro

O "Agentic Retriever" do Managed Knowledge Base executa retrieval multihop - decompondo uma pergunta complexa em múltiplas consultas contra múltiplas bases de conhecimento - e se integra com LangChain, CrewAI e LlamaIndex via MCP. A vantagem de centralizar essa camada, em vez de deixar cada agente falar diretamente com cada fonte, é rastreabilidade: cada consulta multihop fica registrada num único ponto, não espalhada entre integrações artesanais de times diferentes.

Grounding externo sem abrir brecha de dados

O outro lado do problema é acesso a informação atual do mundo externo - o motivo de existir o Web Search no Bedrock AgentCore. A ferramenta devolve trechos, URLs, títulos e datas de publicação para o agente raciocinar em cima de informação atual, mantendo "zero data egress" do ambiente AWS do cliente. Essa é a diferença entre um agente buscando na web de forma governada e um agente com acesso irrestrito à internet: o dado da empresa nunca sai do ambiente controlado, mesmo quando o agente está buscando informação de fora.

Políticas de retenção, logs e aprovação humana

Nenhuma dessas ferramentas substitui política - elas viabilizam aplicá-la de forma consistente. Definir por quanto tempo dados indexados ficam retidos, quem aprova a inclusão de uma nova fonte, e quais consultas exigem aprovação humana antes de uma ação (não apenas uma busca) continuam sendo decisões organizacionais, não técnicas.

Uma checklist de dez pontos

  1. Inventário de fontes - conector central, não integração artesanal por time
  2. Classificação de dados - o que é sensível, o que é público
  3. Escopo de acesso - por agente, não por sistema inteiro
  4. RAG governado - chunking e parsing padronizados centralmente
  5. MCP governado - retrieval centralizado, com rastro de cada consulta
  6. Políticas de retenção - prazo definido para dado indexado
  7. Logs de acesso - cada consulta e retrieval registrado
  8. Aprovação humana - para ações, não só para buscas
  9. Monitoramento - alertas para padrões de acesso fora do esperado
  10. Revisão de risco - periódica, não só na criação da integração

Fontes