Agentes de IA

Matriz RACI para agentes de IA: guia prático

Aprenda a criar uma matriz RACI para agentes de IA com dono operacional, responsáveis técnicos, aprovações, suporte e decisões por etapa do ciclo de vida.

Um agente com vários envolvidos pode continuar sem dono

Comercial pediu a automação. Tecnologia conectou o CRM. Um fornecedor montou o agente. Segurança aprovou o piloto. Operações acompanha os erros. Quando a qualidade cai, cada parte espera que outra decida o que fazer.

A lista de participantes é grande. A responsabilidade permanece difusa.

Uma matriz RACI organiza quem executa, quem responde pelo resultado, quem precisa ser consultado e quem deve ser informado. Para agentes de IA, a matriz precisa acompanhar decisões concretas do ciclo de vida: prioridade, fonte, acesso, avaliação, publicação, incidente, mudança e desligamento.

Preencher quatro letras ao lado de departamentos não resolve o problema. A matriz só funciona quando cada linha representa uma decisão ou entrega observável, existe uma autoridade final e o papel vem acompanhado de prazo, evidência e rota de exceção.

O que significa RACI

RACI é uma forma de distribuir participação no trabalho.

R: responsável pela execução

A pessoa ou equipe que realiza a atividade. Pode haver mais de um responsável quando a entrega exige trabalho conjunto, embora o excesso costume esconder uma decomposição ruim.

A: autoridade que responde pelo resultado

É quem aceita a entrega, resolve conflito e presta contas pelo efeito. Cada linha deve ter uma autoridade clara. Em inglês, essa posição costuma aparecer como accountable.

C: consultado antes da decisão

Contribui com conhecimento, restrição ou validação necessária. A consulta é de mão dupla e precisa ocorrer antes do compromisso.

I: informado

Recebe o resultado ou a mudança para coordenar outra responsabilidade. Informação não concede poder de veto nem transfere execução.

A distinção mais importante está entre R e A. Um fornecedor pode construir o agente. Tecnologia pode manter a integração. A área de negócio continua respondendo pelos critérios e pelo resultado do processo.

Por que agentes exigem uma matriz mais cuidadosa

Software tradicional também precisa de responsabilidades. Agentes ampliam a necessidade porque combinam comportamento probabilístico, dados empresariais, ferramentas e consequências no fluxo real.

O mesmo agente atravessa vários domínios

Um agente comercial pode ler CRM, e-mail, contratos e calendário; usar um modelo externo; preparar uma mensagem; criar tarefa; e pedir aprovação. Cada fronteira tem autoridade própria.

Qualidade depende da operação

Tecnologia consegue medir erro de API e latência. O comercial precisa dizer se a próxima ação faz sentido, se a fonte está atualizada e se o agente respeitou o estágio da negociação.

O comportamento muda sem alterar o código principal

Modelo, prompt, fonte, documento, política, ferramenta ou volume podem mudar a saída. A matriz precisa incluir quem autoriza e verifica essas alterações.

Incidentes pedem decisões rápidas

Quando há mistura entre clientes, envio indevido ou duplicação em lote, alguém precisa poder suspender a capacidade. Uma fila de consultas entre departamentos aumenta o dano.

O agente depende de trabalho humano

Aprovação, correção, curadoria, suporte e tratamento de exceções fazem parte da operação. Se essas tarefas não possuem dono e capacidade, o agente apenas cria outra fila.

Comece pela unidade de trabalho

Uma matriz genérica para "projeto de IA" fica vaga demais. Escolha uma unidade reconhecida pelo processo.

Exemplos:

  • oportunidade comercial preparada;
  • chamado triado;
  • nota fiscal conferida;
  • contrato revisado;
  • reunião transformada em tarefas;
  • cadastro validado;
  • solicitação de compra comparada.

Defina entrada, resultado, sistema oficial, prazo, erro crítico e pessoa que responde pelo processo. Esse recorte mostra quais decisões precisam entrar na matriz.

O inventário de agentes de IA deve guardar função, dono, fontes, ferramentas, estágio, custo e risco. A RACI aprofunda como as responsabilidades se distribuem dentro daquela função.

Separe os papéis que costumam ser confundidos

Patrocinador

Autoriza prioridade, orçamento e continuidade do investimento. Pode cobrar resultado, mas raramente deve aprovar cada detalhe operacional.

Dono operacional

Responde pelo processo atendido. Define critérios, exceções, resultado, adoção e continuidade. Normalmente ocupa o A nas decisões sobre finalidade e efeito do agente.

Responsável técnico

Implementa e mantém runtime, integrações, filas, versões, ferramentas e observabilidade. Responde tecnicamente pela entrega, sem assumir regras que pertencem ao negócio.

Responsável pela fonte

Governa qualidade, acesso, significado e atualização de um sistema ou conjunto de dados. Pode bloquear uso incompatível e corrigir divergências na origem.

Segurança, privacidade ou risco

Define controles e participa de decisões materiais conforme dado, ação e consequência. Sua presença deve acompanhar a classe de risco, em vez de transformar qualquer ajuste em uma revisão ampla.

Avaliador de qualidade

Mantém critérios, casos e revisão. Pode estar na operação, qualidade, risco ou numa função independente, conforme o impacto.

Suporte

Recebe falhas, classifica, resolve o nível adequado e escalona com evidência. Precisa saber onde termina sua autoridade.

Aprovador humano

Decide casos individuais que ultrapassam a autonomia do agente. Esse papel difere do dono do agente e da autoridade de publicação.

Fornecedor

Constrói, hospeda ou mantém componentes conforme contrato. Sua responsabilidade precisa ser delimitada por serviço, evidência e nível de atendimento.

Usuário do processo

Usa a saída, sinaliza erro e participa da adoção. Consultar usuários melhora o desenho, mas não os torna responsáveis pela arquitetura inteira.

Transforme atividades vagas em decisões verificáveis

Linhas como "governança", "dados" e "monitoramento" são largas. Quebre-as em verbos com saída.

Em vez de "dados", use:

  • autorizar a fonte para a finalidade;
  • definir campos permitidos;
  • corrigir registro divergente;
  • aprovar retenção;
  • confirmar descarte.

Em vez de "produção", use:

  • aprovar versão candidata;
  • publicar a versão;
  • ampliar percentual de casos;
  • suspender escrita;
  • restaurar versão anterior.

Em vez de "qualidade", use:

  • definir erro crítico;
  • manter dataset de regressão;
  • revisar amostra;
  • aceitar resultado do piloto;
  • decidir recalibração.

Cada linha deve terminar numa decisão, artefato ou estado que alguém consegue comprovar.

Uma RACI mínima para o ciclo de vida

Considere um agente que prepara oportunidades comerciais e cria próximas ações no CRM.

| Decisão ou entrega | R | A | C | I | |---|---|---|---|---| | definir unidade e resultado | operação comercial | diretor comercial | tecnologia, vendedores | patrocinador | | aprovar fontes e campos | responsáveis pelo CRM e dados | dono da fonte | segurança, operação | tecnologia | | desenhar arquitetura | time técnico | responsável de arquitetura | operação, segurança, fornecedor | patrocinador | | definir ferramentas e acessos | tecnologia | dono do sistema | segurança, operação | suporte | | criar critérios de avaliação | operação e qualidade | dono operacional | tecnologia, usuários | patrocinador | | implementar o agente | tecnologia ou fornecedor | responsável técnico | operação, dados | suporte | | validar versão candidata | qualidade e operação | dono operacional | tecnologia, segurança por risco | usuários piloto | | autorizar produção | responsável pela mudança | autoridade definida pelo risco | operação, tecnologia, segurança | suporte, usuários | | acompanhar qualidade e resultado | operação | dono operacional | tecnologia, qualidade | patrocinador | | responder a falha técnica | suporte e tecnologia | responsável técnico | fornecedor | operação | | conter incidente material | resposta a incidentes | autoridade de incidente | operação, segurança, jurídico quando aplicável | liderança afetada | | alterar fonte ou modelo | time da mudança | autoridade de mudança | operação, dados, segurança | suporte | | ampliar autonomia | operação e tecnologia | dono operacional | risco, qualidade | patrocinador | | desligar o agente | tecnologia e operação | dono do portfólio | dados, segurança, fornecedor | usuários |

Essa tabela é um ponto de partida. A organização deve adaptar papéis, alçadas e risco. O princípio permanece: quem executa uma mudança pode ser diferente de quem responde por seu efeito.

A autoridade muda conforme a decisão

Tentar colocar a mesma pessoa como A em todas as linhas cria um gargalo e mistura competências.

Finalidade e resultado

A área de negócio costuma responder. Ela sabe qual perda deve cair, qual qualidade é aceitável e quando o processo deixou de gerar valor.

Arquitetura e integridade técnica

Tecnologia ou arquitetura responde pelos padrões, pela integração e pela condição operacional dos componentes.

Fonte e significado do dado

O responsável pela fonte decide acesso, definição e correção. Tecnologia não deveria declarar sozinho qual registro comercial ou financeiro possui autoridade.

Risco e incidente

A alçada acompanha impacto. Uma falha reversível de resumo pode ficar com a operação. Exposição de dado, transação indevida ou mistura entre clientes aciona autoridade específica de incidente.

Portfólio e orçamento

Patrocinador, comitê ou liderança decide continuar, ampliar ou encerrar investimento com base em adoção, economia, qualidade e risco.

O modelo operacional de IA ajuda a distribuir essas decisões entre núcleo central e áreas. A matriz RACI aplica essa estrutura a uma capacidade concreta.

Inclua decisões de dados

Matrizes de projeto costumam colocar "dados" numa única linha. Para agentes, isso deixa lacunas importantes.

Registre responsabilidades para:

  • escolher a fonte oficial;
  • autorizar finalidade de uso;
  • classificar dados;
  • definir campos mínimos;
  • resolver identidade do cliente ou objeto;
  • tratar divergência entre fontes;
  • manter atualização e validade;
  • corrigir erro na origem;
  • governar índice, cache e memória derivados;
  • revisar retenção;
  • atender exclusão quando aplicável;
  • confirmar descarte no encerramento.

A página sobre fonte da verdade para agentes de IA explica como distribuir autoridade por objeto, campo e evento sem transformar memória do agente em cadastro oficial.

Inclua decisões de acesso e autonomia

A mesma função pode operar em leitura, preparação, escrita limitada ou ação sensível. A RACI precisa dizer quem decide a passagem entre esses níveis.

Linhas importantes:

  • criar identidade do agente;
  • conceder ferramenta;
  • aprovar escopo;
  • revisar acesso;
  • autorizar escrita;
  • definir limite de volume e valor;
  • aprovar exceção emergencial;
  • suspender capacidade;
  • revogar credencial;
  • recertificar acesso;
  • ampliar autonomia;
  • reduzir autonomia depois de desvio.

A matriz de autonomia para agentes de IA organiza níveis de ação e evidências para progressão. A RACI indica quem produz, consulta e aceita essas evidências.

Inclua avaliação e publicação

Uma versão pode mudar por causa de prompt, modelo, ferramenta, fonte, política ou configuração. A matriz deve cobrir o caminho até produção.

Critérios

Quem define qualidade, erros críticos e limites? Normalmente operação e risco participam, com aceite do dono operacional.

Casos de teste

Quem mantém exemplos comuns, exceções e incidentes? A responsabilidade pode ficar com qualidade ou operação, com suporte técnico para execução automatizada.

Execução da avaliação

Quem roda testes, registra resultados e compara versões? Tecnologia ou uma função de avaliação pode executar.

Decisão de publicação

Quem aceita o risco residual e autoriza o alcance? A autoridade depende da consequência, do ambiente e da reversibilidade.

Implantação

Quem publica, acompanha e consegue reverter? O responsável técnico executa conforme o controle de mudanças para agentes de IA.

Misturar todas essas etapas em "aprovar agente" impede saber se a versão falhou por critério ausente, teste incompleto ou decisão fora da alçada.

Inclua operação diária e suporte

Depois da publicação, a responsabilidade costuma desaparecer da agenda do projeto. A RACI precisa continuar válida.

Cubra:

  • observação de disponibilidade;
  • fila e prazo;
  • qualidade por classe;
  • revisão humana;
  • correção de fonte;
  • falha de integração;
  • custo e volume;
  • alerta de segurança;
  • ticket de usuário;
  • escalonamento funcional;
  • manutenção programada;
  • atualização de procedimento;
  • revisão de adoção;
  • decisão de continuidade.

O suporte N1, N2 e N3 para agentes de IA separa recepção, diagnóstico funcional, correção técnica e investigação especializada. A matriz deve apontar autoridade e handoff entre esses níveis.

Defina quem pode parar o agente

Um processo crítico precisa de autoridade de interrupção conhecida antes do incidente.

A matriz deve indicar quem pode:

  • pausar novas entradas;
  • interromper uma ferramenta;
  • suspender escritas;
  • cancelar tarefas em curso;
  • bloquear uma identidade;
  • reduzir o agente para leitura;
  • ativar contingência;
  • autorizar retorno gradual.

A pessoa que detecta o problema pode iniciar uma contenção predefinida sem esperar a autoridade final de investigação. O alcance e os critérios precisam estar documentados.

O guia de kill switch para agentes de IA detalha interrupção por camada e confirmação de parada.

Adicione prazo, evidência e substituto

A RACI tradicional mostra participação. Para operar, acrescente três colunas.

Prazo

Quanto tempo cada decisão pode esperar? Aprovação de versão e contenção de incidente possuem relógios diferentes.

Evidência mínima

O que precisa acompanhar a decisão? Exemplos:

  • resultado do dataset de regressão;
  • divergências do modo sombra;
  • lista de permissões;
  • impacto estimado;
  • plano de reversão;
  • confirmação do sistema de destino;
  • casos afetados;
  • assinatura da versão.

Substituto ou escalação

Quem assume quando a autoridade está indisponível? Qual condição move a decisão para outro nível?

Uma matriz sem relógio pode criar responsabilidade formal e atraso operacional. Uma matriz sem evidência transforma aprovação em opinião.

Use classes de risco para evitar burocracia uniforme

A mesma RACI para qualquer agente faz as rotas simples esperarem e as rotas sensíveis passarem com pouca análise.

Crie classes baseadas em fatos como:

  • leitura ou escrita;
  • reversibilidade;
  • comunicação externa;
  • valor financeiro;
  • dado pessoal ou confidencial;
  • escala e velocidade;
  • impacto sobre cliente;
  • obrigação regulada;
  • capacidade de interromper;
  • disponibilidade de revisão humana.

Um agente interno que prepara rascunhos pode ter aprovação local. Um agente que altera pagamento ou envia comunicação em lote pede autoridade, teste e contenção adicionais.

Risco define a rota. O nome "agente de IA" sozinho não deveria acionar o rito máximo.

Conecte a matriz aos sistemas de trabalho

Uma planilha esquecida não governa execução. Ligue cada responsabilidade ao ponto onde o trabalho acontece.

Exemplos:

  • dono e versão no inventário de agentes;
  • aprovador dentro do workflow de mudança;
  • responsável pela fonte no catálogo de dados;
  • escalonamento no sistema de tickets;
  • autoridade de incidente no runbook;
  • aprovador humano no próprio pedido;
  • dono operacional no painel de qualidade;
  • responsável técnico nos alertas;
  • substituto no calendário de cobertura;
  • decisão final no registro de mudanças.

A RACI é uma referência. Os controles de identidade, política e workflow continuam necessários para impedir que uma decisão ultrapasse a alçada.

Evite estes desenhos frágeis

Um A por departamento inteiro

"Negócio" ou "TI" não identifica autoridade. Use função ou papel operacional com substituição definida.

Vários A na mesma linha

Duas autoridades finais costumam produzir veto cruzado. Separe a decisão ou defina uma alçada de desempate.

Fornecedor como dono do resultado

O fornecedor responde pelo serviço contratado. A empresa continua responsável pela finalidade, pelos dados, pelos critérios e pela consequência do processo.

Segurança consultada em tudo

Consulta indiscriminada cria fila e reduz atenção sobre decisões materiais. Defina gatilhos de risco que exigem participação.

Operação apenas informada

Se a área usa a saída e responde pelo resultado, ela precisa participar dos critérios, avaliação e continuidade.

Tecnologia como A de todas as linhas

Tecnologia pode responder por arquitetura e disponibilidade. Não deve decidir sozinha preço, política comercial, regra financeira ou qualidade funcional.

Usuário como responsável por corrigir o sistema

Usuários podem sinalizar e revisar. Correções recorrentes precisam chegar a um dono capaz de alterar fonte, regra, interface ou versão.

Matriz criada uma vez

Pessoas, fornecedores, riscos e arquitetura mudam. Uma RACI vencida transmite falsa segurança.

Como construir a matriz em oito passos

1. Escolha o agente e a unidade

Nomeie a função operacional e a entrega concluída. Evite começar por uma plataforma inteira.

2. Desenhe o ciclo de vida

Liste descoberta, desenho, dados, acesso, implementação, avaliação, publicação, suporte, mudança, incidente e encerramento.

3. Quebre cada etapa em decisões

Use verbos e saídas verificáveis. Separe criação, aceite e execução quando pertencem a autoridades diferentes.

4. Liste papéis reais

Use funções que existem e possuem capacidade. Não invente um comitê para preencher a tabela.

5. Atribua A primeiro

Defina quem responde por cada decisão. Se isso gerar disputa, a matriz encontrou um problema que precisa ser resolvido antes da automação.

6. Atribua R, C e I

Mantenha consultados e informados no mínimo necessário. Uma matriz cheia de C pode ser um calendário de reuniões disfarçado.

7. Adicione prazo, evidência e escalação

Transforme participação em contrato operacional.

8. Simule casos

Percorra uma mudança comum, uma falha de integração, uma queda de qualidade, um incidente e o desligamento. Confirme se cada decisão encontra autoridade sem depender de memória pessoal.

Métricas que revelam responsabilidade mal desenhada

Observe:

  • decisões vencidas por tipo;
  • alertas sem reconhecimento;
  • aprovações devolvidas por falta de evidência;
  • tickets reencaminhados várias vezes;
  • falhas recorrentes sem correção estrutural;
  • agentes sem dono ativo;
  • acessos sem recertificação;
  • versões em produção sem aceite registrado;
  • incidentes sem autoridade de contenção;
  • revisões humanas acumuladas;
  • exceções sem prazo;
  • decisões concentradas na mesma pessoa;
  • fornecedor executando atividades fora do contrato;
  • discrepância entre RACI e workflow real.

A matriz pode parecer completa e continuar errada. A operação revela isso quando trabalho espera, retorna ou fica sem decisão.

Checklist da matriz RACI

  • A unidade de trabalho está clara?
  • Cada linha termina em decisão, artefato ou estado?
  • Existe um A por linha?
  • O dono operacional responde por finalidade e resultado?
  • Tecnologia responde pelas decisões técnicas adequadas?
  • Fontes e dados possuem autoridade própria?
  • A publicação separa teste, aceite e execução?
  • A operação diária está coberta depois do piloto?
  • Existe autoridade para interromper cada capacidade?
  • Incidente possui rota diferente de falha comum?
  • A matriz muda conforme classe de risco?
  • Fornecedores possuem escopo contratual explícito?
  • Aprovações carregam evidência mínima?
  • Decisões possuem prazo e substituto?
  • Os papéis aparecem nos workflows e alertas reais?
  • A matriz possui dono e data de revisão?

Responsabilidade precisa chegar ao ponto da decisão

A matriz RACI ajuda quando torna visível quem executa e quem responde em cada passagem do agente. Ela impede que a área entregue o processo para tecnologia, que tecnologia receba critérios vagos e que o fornecedor vire dono informal de uma consequência que não controla.

Comece por uma unidade de trabalho e pelo ciclo de vida completo. Defina autoridade antes de distribuir consultas. Acrescente prazo, evidência e escalação. Depois, coloque esses papéis nos sistemas que publicam versões, aprovam casos, recebem alertas e interrompem capacidades.

O agente deixa de ser um projeto compartilhado por todos e assumido por ninguém. Ele passa a ocupar uma função operacional com dono, suporte, limites e decisões rastreáveis.