ADOP: A Plataforma de Engenharia de Dados com Agentes de IA que Reduz Semanas para Horas

O problema que a ADOP veio resolver

Equipes de engenharia de dados vivem um ciclo repetitivo e desgastante: cada nova fonte de dados exige semanas de trabalho manual — escrevendo Extração, Transformação e Carga (ETL), criando verificações de qualidade à mão, atualizando modelos semânticos e validando conformidade regulatória. A Plataforma de Operações de Dados Agênticos (ADOP) na AWS foi projetada justamente para quebrar esse ciclo.

Trata-se de uma arquitetura de referência construída sobre o Amazon Bedrock que usa agentes de Inteligência Artificial (IA) especializados para automatizar o ciclo completo Bronze → Silver → Gold, com controles configuráveis de governança e conformidade regulatória aplicados desde o momento do onboarding.

Para líderes de engenharia de dados, a mudança é significativa em três frentes: os engenheiros deixam de gastar a maior parte do tempo em encanamento de pipelines e passam a entregar produtos de dados; a conformidade sai do papel de portão final e passa a ser um controle inline aplicado no onboarding; e a arquitetura — não o modelo de IA — governa como cada ferramenta de codificação com IA (Claude Code, Kiro, Cursor, Codex) interage com os sistemas de dados.

Agentes no desenvolvimento, artefatos na produção

Essa é a escolha de design que diferencia a ADOP de uma plataforma agêntica comum. A ADOP é um acelerador em tempo de construção, não uma dependência em tempo de execução. Os agentes rodam em ambientes de desenvolvimento, onde raciocinam, propõem e geram: código ETL, verificações de qualidade, definições de camada semântica e controles de regulação. Os engenheiros revisam o resultado. O processo de Integração e Entrega Contínua (CI/CD) então promove os artefatos gerados — PySpark determinístico, SQL, DAGs do Airflow, políticas de Gerenciamento de Identidade e Acesso (IAM) e Cedar — para staging e produção.

No padrão padrão da ADOP, a produção executa artefatos determinísticos sem chamar nenhum modelo. Organizações que precisam de inferência com modelo em tempo de execução podem estender a arquitetura usando endpoints do Amazon Bedrock, mas o código de pipeline gerado permanece estático e auditável.

Como a ADOP se diferencia de assistentes de código genéricos

Ferramentas como GitHub Copilot ou o próprio Claude sem contexto são assistentes de propósito geral: brilhantes, mas sem opiniões sobre arquitetura. Apontados para uma plataforma de dados, cada engenheiro acaba com uma arquitetura diferente a cada dia. A ADOP é opinativa por design. Ela envolve esses mesmos modelos com:

• Uma faixa restrita — habilidades e prompts de engenharia de dados, não “qualquer coisa que você digitar”.
• Filosofia da empresa incorporada — seus padrões vivem no design, não na memória de alguém.
• Sem improvisação arquitetural do Modelo de Linguagem Grande (LLM) — o modelo preenche o blueprint, não o desenha.
• Guardrails de política e regulação — controles aplicados em tempo de construção, não apenas na revisão.
• Um fluxo de onboarding único para toda a empresa — cada fonte chega da mesma forma, sempre.

A diferença resume bem: ferramentas genéricas tornam um desenvolvedor mais rápido. A ADOP torna todos os desenvolvedores consistentes.

Arquitetura: como os agentes se organizam

A ADOP é um framework de codificação com IA que constrói pipelines de dados end-to-end na AWS e em ambientes multi-cloud. Ela lança um Agente de Onboarding de Dados no Claude Code via Amazon Bedrock, usando o recurso de Fluxo de Trabalho Dinâmico do Claude Code para criar sub-agentes especializados para cada estágio da construção do pipeline.

Sub-agentes

Os sub-agentes cuidam de geração de metadados, dedução de ontologia de dados, verificações de qualidade, transformações ETL e orquestração (Airflow ou AWS Step Functions). Os requisitos são enriquecidos iterativamente por meio de interação conversacional, e cada artefato é validado localmente antes do deploy na AWS, com aprovação humana no loop.

Motor de Decisão (clone de IA)

O Motor de Decisão funciona como uma versão codificada em IA do arquiteto corporativo da empresa. Ele incorpora as diretrizes da organização, padrões tecnológicos e filosofia de design diretamente no processo de construção. Isso promove consistência entre os desenvolvedores e reduz a fragmentação que ocorre quando equipes usam ferramentas genéricas sem guardrails compartilhados.

Guardrails e conformidade

Os sub-agentes são restringidos pelo contrato arquitetural: regras de roteamento de ferramentas, políticas de autorização Cedar, invariantes e prompts de conformidade inline. A implementação de referência aponta para AWS, mas o framework se estende a outros serviços com Interface de Linha de Comando (CLI) ou interface do Protocolo de Contexto de Modelo (MCP), suportando ambientes híbridos e multi-cloud.

Para conformidade regulatória, um prompt de regulação por framework de governança pode ser aplicado no onboarding — a equipe jurídica revisa um arquivo de prompt, não o código da aplicação. Cada decisão dos agentes é rastreada via AgentTrace (intenção, ferramenta selecionada, resultado, custo) e publicável no Amazon CloudWatch ou em um sink OpenTelemetry para auditoria.

Casos de uso

A ADOP se aplica onde a velocidade de engenharia de dados é travada por onboarding manual e overhead de conformidade. Os padrões mais comuns incluem:

• Onboarding de dados corporativos em escala — descreva uma nova fonte em linguagem natural. Os agentes cuidam de inferência de schema, ETL, verificações de qualidade e atualizações da camada semântica.
• Pipelines regulados em saúde e serviços financeiros — controles configuráveis aplicados por dataset via prompts de governança dedicados (GDPR, HIPAA, SOX, PCI DSS, CCPA).
• Camadas Gold prontas para IA — populadas e mantidas automaticamente para Business Intelligence (BI) e features de Aprendizado de Máquina (ML).
• Governança de desenvolvimento multi-ferramenta — Claude Code, Kiro, Cursor e Codex operam a partir do mesmo contrato arquitetural.

Como começar em dois passos

O ponto de partida é clonar o repositório:

git clone https://github.com/aws-samples/sample-Agentic-Ai-Data-Operations.git

Em seguida, faça upload de um dataset para o Amazon Simple Storage Service (Amazon S3) ou armazenamento local e execute um prompt adaptado. O exemplo abaixo usa dados fictícios apenas para fins ilustrativos — não representa dados reais de Informação Pessoalmente Identificável (PII) e não constitui orientação de conformidade regulatória ou aconselhamento jurídico:

/onboard-workflow Onboard attendance data from s3://amzn-s3-demo-source-bucket/demo_landing/attendance.csv into Silver with dedup on (employee_id, check_in) and not-null policy on employee_id and check_in,and into a flat denormalized Gold Iceberg table aggregated daily-per-employee with derived measures(hours_worked_clean, attendance_rate, late_arrival_flag, overtime_hours, absence_category). Run daily at 03:00 UTC. Apply data governance controls: hash/pseudonymize PII fields in Silver, suppress or mask sensitive fields in Gold, enforce retention policies, and log processing metadata. Apply guidelines (This example is illustrative only and does not constitute compliance guidance.) Please profile the data first, then propose your recommended quality thresholds and transforms before generating any code.

Da prova de conceito à produção

As primeiras semanas são intensas em arquitetura porque codificar seus padrões — não construir pipelines — é o investimento único. Depois que o contrato existe, cada nova fonte é um prompt, não um projeto. Equipes que adotam esse padrão relatam compressão significativa nos prazos de onboarding de fontes subsequentes, com a curva se achatando ainda mais à medida que a memória de rastreamento de habilidades se acumula.

Estratégia de rollout em fases

O plano de adoção sugerido divide-se em três fases. Na Fase 1 (Semanas 1–3), o piloto envolve dois ou três engenheiros campeões e uma fonte de dados não crítica. Na Fase 2 (Semanas 4–6), a expansão alcança o time completo de plataforma, com 3 a 5 fontes adicionais de complexidade crescente. Na Fase 3 (Semanas 7–12), o rollout organizacional ocorre com novas fontes fluindo pela ADOP e pipelines existentes migrando oportunisticamente durante janelas de manutenção.

Quatro indicadores-chave devem ser monitorados: tempo de ciclo de onboarding de fontes; taxa de aceitação de artefatos na primeira passagem; pontuação de satisfação dos engenheiros via pesquisas anônimas; e taxa de conformidade dos guardrails, medindo a consistência com que os pipelines gerados passam nas verificações automatizadas sem intervenção manual.

Segurança, privacidade e IA responsável

Gerenciamento de segredos e isolamento de dados

Segredos não entram no contexto dos agentes. Credenciais de banco de dados, chaves de API e tokens de serviço são resolvidos em tempo de deploy via AWS Secrets Manager. Os agentes referenciam ARNs ou variáveis placeholder — eles não veem nem processam valores reais de credenciais. Dados sensíveis ficam no lugar: os agentes trabalham com metadados de schema, contagens de linhas de amostra e estatísticas de colunas, não com dados brutos de produção.

Privacidade e isolamento de rede

As interações com o Claude via Amazon Bedrock não são retidas para treinamento do modelo (consulte o FAQ de Privacidade e Segurança de Dados do Amazon Bedrock). Prompts e respostas existem apenas durante a sessão, e a inferência permanece dentro dos limites da conta AWS. O modelo de desenvolvimento local-first significa que os agentes rodam nas máquinas dos desenvolvedores ou dentro da Nuvem Privada Virtual (VPC) — nenhum dado sai da rede sem configuração explícita.

Revisão humana obrigatória

Artefatos gerados — especialmente controles de conformidade e regulação — devem ser revisados por engenheiros qualificados antes de serem promovidos para produção. LLMs podem produzir lógica plausível, mas incorreta. Regras de mascaramento, políticas de retenção ou controles de acesso gerados podem estar incompletos ou sutilmente errados. Trate cada controle gerado como não verificado até que seja validado pela equipe jurídica ou de compliance.

Controles do Amazon Bedrock Guardrails

A ADOP trata o Amazon Bedrock Guardrails como controles obrigatórios de produção na arquitetura. Três capacidades se aplicam aos agentes na camada de API: filtragem de conteúdo (bloqueia outputs fora do escopo de engenharia de dados), validação de fundamentação (verifica que os outputs dos agentes estão ancorados nos metadados de schema e no contrato arquitetural) e filtros de informação sensível (detecção de PII e filtros baseados em regex que evitam que credenciais ou dados regulados apareçam nas respostas dos agentes ou no código gerado). Esses controles rodam inline a cada invocação de agente e são configurados uma vez no contrato arquitetural, sendo aplicados uniformemente em todos os sub-agentes.

Recursos adicionais

• Comece com a ADOP no GitHub
• Saiba mais sobre o Amazon Bedrock
• Leia a documentação do Amazon Bedrock
• Guia sobre hospedagem de agentes de codificação no Amazon Bedrock AgentCore — quando os agentes ADOP superarem o desenvolvimento local, este guia cobre a promoção para hosting gerenciado no AgentCore para execução persistente e escalável.
• Arquitetura SoAL (Spark on AWS Lambda) — se os pipelines gerados pela ADOP precisarem compilar código PySpark, esta arquitetura pode reduzir significativamente a contagem de tokens executando jobs Spark sem servidor.

Fonte

Agentic Data Operations Platform (ADOP): Data engineering into hours (https://aws.amazon.com/blogs/machine-learning/agentic-data-operations-platform-adop-data-engineering-into-hours/)