Como Estruturar a Inteligência Artificial em Escala nas Empresas

Na primeira, times distintos conseguem consumir APIs de modelos, implementar pipelines de RAG, criar copilotos ou experimentar agentes de forma independente. Na segunda, a organização consegue fazer tudo isso de forma repetível, em diferentes domínios de negócio, mantendo padrões consistentes de arquitetura, segurança, identidade, observabilidade, avaliação, custos, governança e operação.

Essa diferença parece irrelevante quando existem dois ou três experimentos. Ela se torna um problema de arquitetura quando existem 20, 50 ou 100 iniciativas concorrentes.

É nesse ponto que se torna necessária uma função central de AI Center of Excellence (AI CoE).

Não necessariamente um departamento formal intitulado "CoE". Mas alguma estrutura organizacional precisa ser proprietária da camada de controle da Inteligência Artificial da empresa.

O Microsoft Cloud Adoption Framework posiciona explicitamente o AI CoE como estrutura destinada a eliminar adoção fragmentada e não governada de IA [¹]. A AWS trabalha com modelos centralizados e federados de AI/ML CoE [²][³]. A discussão, portanto, não é simplesmente "centralizar ou descentralizar", mas o que deve ser centralizado e o que deve permanecer distribuído.

A tese central deste artigo é:

"

Centralizar a camada de controle. Distribuir a camada de execução.

O problema começa quando cada squad constrói sua própria plataforma de IA

Considere uma empresa com múltiplas unidades de negócio.

O time A precisa de atendimento inteligente e integra diretamente com a API da OpenAI. O time B precisa analisar contratos e adota Claude. O time C implementa um RAG com Gemini. O time D constrói um agente que executa operações internas. O time E cria seu próprio pipeline de embeddings.

Tecnicamente, nenhum desses movimentos é necessariamente incorreto de forma isolada.

O problema se materializa meses depois, quando a empresa passa a operar simultaneamente:

• cinco estratégias distintas de autenticação;
• quatro implementações independentes de RAG;
• três bancos vetoriais sem padronização;
• múltiplas versões de modelos de embedding;
• diferentes estratégias de chunking;
• prompts armazenados diretamente no código-fonte;
• credenciais de provedores distribuídas sem gestão centralizada;
• modelos sendo invocados diretamente pelas aplicações, sem camada de abstração;
• nenhuma taxonomia comum de avaliação;
• diferentes mecanismos de auditoria;
• diferentes políticas de retenção de prompts e dados de inferência;
• diferentes mecanismos de PII masking;
• nenhum orçamento central de tokens;
• agentes operando com diferentes níveis de permissão;
• nenhuma visão consolidada sobre risco operacional.

Isso configura architecture drift, e será seguido, quase inevitavelmente, por governance drift.

A organização passa a possuir vários sistemas de IA, mas não possui uma arquitetura de IA.

O CoE não deveria ser uma fábrica de projetos

Existe um antipattern frequente na implantação de Centers of Excellence: a empresa centraliza todos os especialistas de IA e determina que qualquer projeto de IA precisa passar por esse time.

Essa abordagem resolve parte da fragmentação, mas introduz outro problema: throughput. O CoE se transforma em uma fila, e quando dezenas de áreas passam a demandar IA simultaneamente, o resultado previsível é gargalo operacional.

Por essa razão, o modelo mais adequado para o CoE é uma combinação de Platform Team + Architecture Function + Governance Function + Enablement Function. O trabalho principal não deveria ser construir todos os produtos de IA da empresa. Deveria ser construir a paved road, a infraestrutura pavimentada que permite que esses produtos sejam construídos de maneira consistente, segura e governada.

"

CAMADA DE CONTROLE (AI CoE)

• Architecture
• Platform Engineering
• AI Security
• Governance
• GenAIOps / LLMOps
• Evaluation
• FinOps

⬇️ (provê os fundamentos para)

CAMADA DE EXECUÇÃO (Product Squads)

• Squad A: Fraud / Risk
• Squad B: Customer Experience
• Squad C: Operations

O domínio permanece nos squads. Os fundamentos de IA não precisam ser reconstruídos por cada squad.

O ativo mais importante do CoE é uma AI Platform

Quando IA passa a ser utilizada de forma transversal na organização, permitir acesso direto e indiscriminado dos sistemas aos provedores de modelos produz forte acoplamento e dificulta governança.

Uma arquitetura corporativa sustentável deve introduzir uma camada intermediária, um AI Gateway, que funciona como ponto de integração e enforcement entre aplicações e provedores:

"

Fluxo com Enforcement:

1. Applications / Agents / Copilots
2. ⬇️ AI Gateway (enforcement point)
3. ⬇️ Serviços Orquestrados: Policy Engine, Model Router, Semantic Cache
4. ⬇️ Provedores: OpenAI, Anthropic, Gemini, Vertex/Bedrock, Self-hosted
5. ⬇️ Governance & Security aplicados a toda requisição

Um ponto importante: o AI Gateway funciona como ponto de enforcement e integração, mas não deve ser proprietário de todas as capacidades que orquestra. Em uma arquitetura real, ele delega para serviços especializados:

• Policy Decision Point
• Model Router
• Guardrail Service
• Identity / AuthZ
• Cost Metering
• Observability Collector
• Semantic Cache
• Model Registry

Essa distinção evita que o gateway se torne um monólito, um God Service que concentra toda a complexidade. Ele coordena; os serviços resolvem.

As capacidades que passam pelo gateway incluem autenticação e autorização, tenant isolation, model allowlist, rate limiting, cost attribution, request tracing distribuído, prompt filtering (PII detection), DLP, model routing inteligente, circuit breaker, caching e auditoria.

Com essa camada, substituir o modelo utilizado por determinada workload deixa de exigir alteração em dezenas de aplicações. A decisão de roteamento pode ser resolvida dinamicamente com base em:

routing_policy = capability + data_classification + latency_requirement + cost_budget + region + compliance + context_window + model_quality

Nesse modelo, "qual LLM utilizamos?" deixa de ser uma decisão estática de arquitetura e passa a ser uma policy de runtime.

Camada de controle versus camada de execução

Uma forma eficaz de organizar responsabilidades é separar explicitamente dois planos operacionais e, mais importante, mostrar como esses componentes se conectam em runtime.

O fluxo de uma requisição segue a direção das workloads em direção aos provedores, passando pela plataforma:

"

1. CAMADA DE CONTROLE (CoE)

• Developer Portal
• AI Platform APIs
• Registries (Prompt, Model, Agent)
• Policy Engine & Release Gates

⬇️

2. CAMADA DE EXECUÇÃO (Runtime)

• Workloads: Squads A, B, C (Applications, Agents, Copilots)
• ⬇️
• AI Gateway
• ⬇️
• Model Router (direcionando para GPT, Claude, Gemini, etc.)

Embora Gateway e Model Router sejam capacidades geridas e governadas pelo CoE, eles operam no runtime da camada de execução. A camada de controle define políticas, configuração e critérios de aprovação; a camada de execução aplica essas decisões durante as requisições.

Em termos práticos, essa distinção se traduz em:

Predominantemente sob responsabilidade do CoE:

• Model Registry, Prompt Registry, Agent Registry
• Evaluation Registry, Observability Standards, Risk Classification
• Policy Engine, Release Gates, Cost & Security Controls
• Reference Architectures e Governance

Predominantemente sob responsabilidade dos times de produto:

• Business Use Cases, Domain Logic, Domain APIs
• User Experience, Domain Knowledge
• RAG Collections, Agent Workflows
• Product SLOs, Business Metrics e Business Outcomes

Essa separação resolve um conflito recorrente. O CoE não precisa deter conhecimento profundo sobre fraude, crédito, RH, logística ou atendimento. Mas também não faz sentido cada área reinventar observabilidade de LLM, segurança de agentes, model routing ou evaluation framework.

O AI Gateway é apenas uma peça. O verdadeiro produto é a AI Platform

Uma plataforma corporativa de IA com nível adequado de maturidade possui múltiplos serviços compartilhados que vão além do gateway. Uma AI PLATFORM completa inclui:

• AI Gateway e Model Router
• Registries (Model, Prompt, Agent)
• Evaluation Platform e Experiment Tracking
• Guardrails e Semantic Cache
• Observability e Cost Management
• Feature / Context Services e RAG Services
• Policy Engine, Secrets Management e Audit

Essa plataforma transforma IA de uma coleção de SDKs e integrações pontuais em uma capability corporativa.

Mas existe um princípio fundamental que muitas organizações negligenciam:

AI Platform também é produto

A plataforma não é bem-sucedida porque existe. Ela é bem-sucedida quando os times preferem utilizá-la a construir soluções próprias. Isso exige tratá-la com a mesma disciplina de qualquer produto:

• Platform Product Owner e Roadmap
• Internal Customers e Adoption Metrics
• Developer NPS e SLOs da plataforma
• Backward Compatibility e Deprecation Policies
• Versioned APIs e Platform Documentation

Sem product thinking, existe um antipattern previsível: o CoE se transforma em fábrica de frameworks internos que ninguém adota.

Developer Experience é o que conecta plataforma a adoção

Uma AI Platform enterprise madura precisa investir explicitamente em Developer Experience (DX). O catálogo de serviços compartilhados só gera valor se os squads conseguirem consumi-lo com baixa fricção:

• Developer Portal e CLI
• SDKs (Platform, Observability, Agent, RAG, Evaluation)
• Templates, Scaffolding e CI/CD Templates
• Golden Paths e Reference Implementations
• Policy Libraries

Isso materializa o que platform engineering chama de golden path: o caminho que entrega conformidade, segurança e observabilidade por padrão, sem exigir que cada time descubra como implementar cada uma dessas dimensões.

O desenvolvedor executa:

ai-platform create rag-service

E recebe nativamente:

• ✅ Tracing e Observability
• ✅ Authentication e Secrets
• ✅ Evaluation e Guardrails
• ✅ Cost tracking e Audit
• ✅ CI/CD e Model routing

O desenvolvedor permanece livre para resolver o problema de negócio, mas não precisa reconstruir a fundação de segurança, observabilidade e governança.

RAG exige plataforma e governança dedicadas

Outro antipattern recorrente é tratar Retrieval-Augmented Generation como uma implementação trivial de documentos ➔ embedding ➔ vector database ➔ LLM.

Em produção, a complexidade é consideravelmente maior. Uma plataforma de RAG enterprise-grade precisa lidar com, no mínimo:

"

Pipeline de RAG: Sources ➔ Connectors ➔ Parsing ➔ Normalization ➔ PII Detection / Data Classification ➔ Chunking ➔ Embedding ➔ Indexing ➔ ACL Propagation ➔ Retrieval ➔ Reranking ➔ Context Assembly ➔ Generation ➔ Evaluation

E precisa ser capaz de responder perguntas operacionais críticas:

• Qual versão do documento produziu determinada resposta?
• Qual versão do modelo de embedding estava ativa naquele momento?
• Qual algoritmo de chunking foi utilizado?
• Qual índice foi consultado e quais documentos foram recuperados?
• Qual foi o score de retrieval para cada documento?
• O usuário possuía autorização para acessar os documentos recuperados?
• O conteúdo recuperado foi efetivamente utilizado na geração da resposta?
• É possível reproduzir os inputs, o contexto, as versões e as condições daquela execução para investigação e comparação de comportamento?

Essas propriedades (rastreabilidade, reprodutibilidade, controle de acesso) precisam fazer parte da arquitetura, não serem adicionadas posteriormente.

O OWASP Top 10 for LLM Applications (2025) classifica Vector and Embedding Weaknesses como categoria própria de risco, ao lado de Prompt Injection, Sensitive Information Disclosure, Excessive Agency e Unbounded Consumption [⁴].

RAG não é apenas uma técnica de recuperação. Ele introduz uma nova superfície de ataque e uma nova dimensão de governança.

Evaluation precisa ser infraestrutura, não verificação manual

Um dos indicadores mais claros de baixa maturidade em IA generativa é a seguinte afirmação:

"

"Testamos alguns prompts e parece que está funcionando."

Software determinístico permite testar com a lógica input → expected_output. Aplicações generativas são probabilísticas por natureza. Por essa razão, o CoE precisa estabelecer uma disciplina corporativa de AI Evaluation como infraestrutura automatizada.

O Google Cloud recomenda explicitamente tratar evaluation como atividade central do desenvolvimento de aplicações generativas, incluindo a criação de datasets que representem cenários normais, críticos e edge cases, com automação progressiva dos testes [⁵].

Uma plataforma de evaluation deve operar com a seguinte estrutura:

"

1. Evaluation Dataset (Golden cases, Adversarial, Edge cases, Safety, Regression) 2. ⬇️ Evaluation Runner 3. ⬇️ Models (Modelo A, Modelo B, etc) 4. ⬇️ Metrics

As métricas de avaliação devem cobrir múltiplas dimensões, dependendo da natureza da workload:

• Qualidade: task_success_rate, factuality, groundedness, faithfulness, answer_relevance, citation_correctness.
• Retrieval: precision@k, recall@k, MRR, NDCG, context_relevance.
• Segurança: prompt_injection_success_rate, jailbreak_success_rate, PII_leakage_rate, policy_violation_rate, unsafe_tool_call_rate.
• Operação: p50_latency, p95_latency, p99_latency, tokens_per_request, cost_per_request, cache_hit_rate, model_error_rate, fallback_rate.
• Agentes: task_completion_rate, tool_success_rate, steps_per_task, human_escalation_rate, human_override_rate, invalid_action_rate, loop_rate.

Isso conduz a um conceito operacional crítico: AI Release Gates.

Um modelo, prompt ou agente não deveria ser promovido para produção com base em aprovação visual de respostas. O gate de release deve ser definido por critérios mensuráveis. Os valores abaixo são ilustrativos; os thresholds devem ser definidos por classe de risco e natureza da workload:

• groundedness >= 0.90
• task_success_rate >= 0.92
• PII_leakage_rate == 0
• critical_policy_failure == 0
• p95_latency <= 3s
• cost_per_request <= budget

Mudou o modelo? Roda evaluation. Mudou o system prompt? Roda evaluation. Mudou o embedding? Roda evaluation. Mudou o chunking? Roda evaluation. Mudou o retriever? Roda evaluation.

Isso é regression testing para sistemas probabilísticos.

Prompt precisa ser tratado como artefato de engenharia

Outro sintoma de IA fragmentada é encontrar construções textuais estáticas no código, espalhadas por dezenas de repositórios, sem versionamento, sem ownership e sem rastreabilidade.

Prompts críticos devem possuir propriedades equivalentes às de outros artefatos de engenharia de software:

• prompt_id e version
• owner e created_at
• approved_by e model_compatibility
• risk_classification e evaluation_dataset
• evaluation_result e deployment_environment
• rollback_version

Uma alteração em prompt pode modificar o comportamento de produção com a mesma magnitude que uma alteração de código. O ciclo de vida deve refletir isso:

"

Prompt Change ➔ Pull Request ➔ Automated Evaluation ➔ Security Checks ➔ Approval ➔ Canary ➔ Production

Essa disciplina aproxima LLMOps da maturidade já consolidada em engenharia de software.

Com agentes, o problema deixa de ser qualidade e passa a envolver autorização

LLMs que apenas geram texto já possuem riscos relevantes de segurança. Agentes introduzem uma dimensão adicional: o modelo passa a executar ações no mundo real.

Um agente pode ser configurado para consultar clientes, consultar saldo, abrir tickets, enviar e-mails, alterar cadastros, realizar pagamentos ou executar workflows inteiros. Isso altera fundamentalmente o modelo de ameaça.

O OWASP classifica Excessive Agency como risco específico: sistemas baseados em LLM que recebem funcionalidades, permissões ou autonomia além do necessário [⁴].

Em uma arquitetura corporativa, autorização não pode residir exclusivamente dentro do prompt. Uma instrução como:

"

"Nunca execute uma transferência acima de R$ 10.000."

não constitui controle de segurança. É uma instrução probabilística e o modelo pode escolher ignorá-la. O controle real deve estar fora do LLM, em camada determinística:

"

Agent ➔ propõe Tool Request ➔ interceptado pelo Policy Engine ➔ (Allow / Deny / Human Approval)

Os princípios de segurança para agentes incluem:

• Least privilege e tool allowlist
• Scoped credentials e short-lived tokens
• Action budgets e step limits
• Timeouts e transaction boundaries
• Idempotency e human approval
• Audit trail estruturado

O modelo pode propor ações. O sistema determinístico deve autorizar. Essa fronteira é inegociável.

Essa é, na verdade, uma das decisões arquiteturais mais consequentes em sistemas agentic: reasoning e autorização são responsabilidades distintas. O LLM pode concluir que a melhor ação seguinte seria executar X. Mas não deve determinar sozinho que possui autorização para executar X. Inteligência e autorização devem ser implementadas em camadas separadas.

Segurança deve ser integrada ao AI SDLC

A segurança de aplicações generativas não pode ser tratada como responsabilidade exclusiva do time que implementou determinado chatbot ou agente.

O OWASP mantém categorias específicas para aplicações GenAI, incluindo Prompt Injection, Sensitive Information Disclosure, Supply Chain Vulnerabilities, Data and Model Poisoning, Improper Output Handling, Excessive Agency, System Prompt Leakage, Vector and Embedding Weaknesses, Misinformation e Unbounded Consumption [⁴].

O Google, através do Secure AI Framework (SAIF), propõe incorporar segurança ao ciclo de vida completo de sistemas de IA, e não adicioná-la como controle posterior ao deploy [⁶].

Isso implica construir um AI Secure SDLC com fases bem definidas:

"

IDEA ➔ Risk Classification ➔ Architecture / Threat Modeling ➔ Development ➔ Offline Evaluation ➔ AI Security Testing ➔ Red Team / Adversarial Testing ➔ Deployment Gate ➔ Canary ➔ Production ➔ Runtime Monitoring ➔ Continuous Evaluation

Essa esteira é inviável de manter se cada squad implementar sua própria versão.

Observabilidade de IA exige instrumentação além de métricas tradicionais

OpenTelemetry, métricas de infraestrutura e APM continuam sendo componentes necessários. Mas são insuficientes para aplicações de IA.

Uma execução de IA precisa ser rastreável com granularidade vinculada a um trace_id único, contendo:

• O user_request original
• A prompt_version exata
• O model e a model_version
• Dados de retrieval (query, documents, scores)
• Detalhes de tool_calls (tool, arguments, authorization_decision, result)
• token_usage, latency e estimated_cost
• guardrail_results
• A final_response

Sem essa instrumentação, responder a perguntas operacionais aparentemente simples se torna impossível:

"

"Por que o agente tomou essa decisão ontem às 14h37?"

Essa é uma pergunta de produção e de compliance, não de pesquisa.

FinOps muda de natureza com a introdução de IA

Em aplicações tradicionais, custo está associado predominantemente a infraestrutura computacional. Em GenAI, a estrutura de custos possui granularidade significativamente maior:

"

Custo da solução = inference + embeddings + retrieval + reranking + storage + vector database + observability + agents/tool calls + evaluation + infrastructure

Se cada squad contrata e utiliza modelos de forma independente, a empresa perde capacidade de otimização e negociação. Uma AI Platform deve permitir chargeback ou showback com atribuição por business_unit, application, tenant, feature, model e environment.

Habilitando métricas econômicas como:

• cost_per_request
• cost_per_customer
• cost_per_successful_task
• cost_per_agent_execution
• tokens_per_feature

A pergunta relevante em nível de arquitetura não é simplesmente "qual modelo custa menos?", mas:

"

"Qual arquitetura entrega o menor custo por tarefa concluída com sucesso, mantendo os níveis requeridos de qualidade e risco?"

Essa reformulação transforma a discussão de procurement em discussão de engenharia.

Model Registry é infraestrutura essencial

Outro problema das arquiteturas distribuídas se manifesta quando cada aplicação escolhe e integra modelos de forma direta (Ex: App A ➔ Modelo X, App B ➔ Modelo Y).

Quando um modelo muda de versão, apresenta regressão, sofre alteração de preço ou precisa ser descontinuado, quem sabe quais aplicações dependem dele?

Um Model Registry corporativo deve ser capaz de responder, para cada modelo:

• model_id e deployment_id
• provider e version
• owner, region e endpoint
• context_window, capabilities, tool_support e structured_output_support
• allowed_use_cases e prohibited_use_cases
• data_classification, data_retention_policy e training_data_usage_policy
• benchmark_results e evaluation_baseline
• cost, latency e provider_sla
• risk_level e security_assessment
• approval_status, fallback_model e deprecation_date

A distinção entre model e deployment é importante: em GenAI corporativa, o mesmo modelo pode ter múltiplos deployments com configurações, regiões e políticas distintas.

A pergunta deixa de ser "podemos usar GPT, Claude ou Gemini?" e passa a ser:

"

"Qual modelo está aprovado para esta classificação de dados, região, nível de risco e tipo de workload?"

Isso é governança operacional, não preferência tecnológica.

Governança precisa ser executável, não documental

Um CoE de baixa maturidade publica documentos de políticas. Um CoE maduro transforma política em policy-as-code:

workload:
  risk_level: high
  data_classification: confidential

policy:
  allowed_models:
    - model-a
    - model-b
  external_provider: false
  pii_detection: required
  human_approval:
    destructive_actions: true
  retention:
    prompts: 0
  evaluation:
    minimum_groundedness: 0.92

O objetivo é que a arquitetura faça cumprir aquilo que a política determina, de forma automática, auditável e consistente.

Governança executável é exponencialmente mais eficaz do que governança documental.

O NIST AI RMF fornece estrutura para organizar essas responsabilidades

O NIST AI Risk Management Framework (AI RMF 1.0) organiza gerenciamento de risco de IA em quatro funções: GOVERN, MAP, MEASURE e MANAGE [⁷].

O NIST também publicou o Generative AI Profile (AI 600-1) com riscos específicos de IA generativa [⁸].

Essas funções se conectam naturalmente com as responsabilidades de um CoE:

GOVERN

Quem é responsável? Quais políticas existem? Quais modelos podem ser utilizados? Quais workloads são classificadas como high-risk?

MAP

Qual é o contexto de uso? Quem será afetado? Quais dados estão envolvidos? Qual nível de autonomia o sistema terá?

MEASURE

Como medimos qualidade? Como testamos segurança? Como avaliamos bias, groundedness ou leakage?

MANAGE

Quais riscos são aceitos? Quais controles são aplicados? Quando o sistema deve ser desligado? Como tratamos incidentes?

Sem uma função organizacional explicitamente responsável por essas dimensões, as responsabilidades acabam fragmentadas entre squads, com cobertura inconsistente e lacunas previsíveis.

ISO/IEC 42001 eleva a discussão para o nível de sistema de gestão

A ISO/IEC 42001:2023 define requisitos para estabelecer, implementar, manter e melhorar continuamente um Artificial Intelligence Management System (AIMS) [⁹].

Essa norma reforça que governança de IA não pode depender exclusivamente da maturidade técnica individual de engenheiros. Ela precisa existir como capacidade organizacional estruturada mediante processos definidos, responsabilidades atribuídas, controles implementados, medição contínua, auditoria periódica e melhoria contínua.

As nove capacidades de um AI CoE

Com base na análise das responsabilidades necessárias, proponho a seguinte estrutura de capacidades para o CoE:

1. AI Architecture: define reference architectures, Architecture Decision Records (ADRs), padrões de integração e technology radar.
2. AI Platform Engineering: constrói e mantém os componentes compartilhados da plataforma.
3. GenAIOps / LLMOps: define padrões de deployment, versionamento, rollback, experimentação e lifecycle management.
4. AI Security: responsável por threat modeling, red teaming, guardrails e runtime protection.
5. AI Governance: define policies, risk classification, model approval workflows e auditabilidade.
6. AI Evaluation: mantém datasets, benchmarks, regression suites e release gates.
7. AI FinOps: gerencia budgets, quotas, model economics e cost attribution.
8. Responsible AI: garante uso apropriado, avaliação de impactos e controles organizacionais.
9. Enablement: fornece SDKs, documentação, templates, treinamento e suporte direto aos squads.

Essas são capacidades organizacionais, não necessariamente nove equipes ou departamentos independentes. Em organizações menores, uma mesma função pode assumir múltiplas capacidades. O importante é que cada uma tenha ownership explícito.

O modelo federado evita dois extremos disfuncionais

O modelo completamente descentralizado (cada squad cria sua própria plataforma) gera duplicação, risco não governado e inconsistência operacional. O modelo completamente centralizado (todos enviam projetos para o CoE desenvolver) gera gargalo e perda de velocidade.

Modelo federado

"

AI CoE (Provê Plataforma e Padrões) ⬇️ Squads A, B, C (Desenvolvem e mantêm as AI Features do negócio)

Esse modelo está alinhado com as recomendações de arquitetura organizacional da AWS [²][³] e da Microsoft [¹] para AI Centers of Excellence.

O KPI do CoE deve medir capacidade, não atividade

Se o CoE mede sucesso por quantidade de POCs, chatbots ou projetos entregues, está medindo atividade, não capacidade.

Indicadores mais relevantes para um CoE orientado a plataforma incluem o percentual de workloads operando sobre a plataforma, % com avaliação automatizada, tempo médio de PoC até a produção, reutilização de componentes, incidentes de segurança, compliance rate, e a cobertura de tracing.

A pergunta que esses indicadores respondem é:

"

Quanto mais fácil, mais rápido e mais seguro ficou para qualquer time da empresa colocar IA em produção?

Conclusão

A primeira onda de IA corporativa foi concentrada em experimentação: APIs, prompt engineering, POCs, chatbots. A próxima etapa é consideravelmente mais complexa. Estamos falando de sistemas compostos por LLMs, RAG, agentes, ferramentas, APIs, bancos de dados, vector stores, políticas, guardrails, evaluators, identidade, observabilidade e aprovação humana.

São sistemas distribuídos, parcialmente probabilísticos e, cada vez mais, capazes de executar ações com consequências reais. Isso exige engenharia, arquitetura, segurança, governança e, acima de tudo, ownership.

Nem toda empresa precisa criar imediatamente um departamento formal chamado AI Center of Excellence. Mas qualquer organização que pretenda operar dezenas de sistemas de IA em produção precisa, cedo ou tarde, criar uma função equivalente, com ownership explícito sobre arquitetura, plataforma, governança, segurança, avaliação, observabilidade, FinOps e lifecycle.

O modelo sustentável é direto:

"

Centralize a camada de controle. Transforme IA em plataforma. Distribua a execução. Mantenha o domínio nos squads. E coloque governança dentro da arquitetura, não ao redor dela.

Quando isso se materializa, o CoE deixa de ser uma estrutura organizacional. Ele se torna aquilo que realmente deveria ser: o sistema operacional da Inteligência Artificial dentro da empresa.

Referências

[1] Microsoft. Establish an AI Center of Excellence. Cloud Adoption Framework for Azure, 2024. Disponível em: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/ai/center-of-excellence

[2] AWS. Establishing an AI/ML Center of Excellence. AWS Prescriptive Guidance. Disponível em: https://docs.aws.amazon.com/prescriptive-guidance/latest/ml-center-of-excellence/

[3] AWS. Generative AI operating models in enterprise organizations. AWS Prescriptive Guidance, 2024. Disponível em: https://docs.aws.amazon.com/prescriptive-guidance/latest/generative-ai-operating-models/

[4] OWASP. Top 10 for LLM and Generative AI Applications, versão 2025. Disponível em: https://genai.owasp.org

[5] Google Cloud. Deploy and operate generative AI applications. Cloud Architecture Center, 2024. Disponível em: https://cloud.google.com/architecture/deploy-operate-generative-ai-applications

[6] Google. Secure AI Framework (SAIF). Disponível em: https://safety.google/saif/

[7] NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, janeiro de 2023. Disponível em: https://www.nist.gov/artificial-intelligence/executive-order-safe-secure-and-trustworthy-artificial-intelligence

[8] NIST. Generative Artificial Intelligence Profile. NIST AI 600-1, julho de 2024. Disponível em: https://airc.nist.gov/Docs/1

[9] ISO/IEC 42001:2023. Information technology: Artificial intelligence: Management system. International Organization for Standardization, 2023.