1.2.1 1.2.1 Foco em Valor de Negócio

Toda iniciativa de IA deve estar diretamente ligada a um objetivo de negócio claro e mensurável. Priorizamos casos de uso que ofereçam o maior retorno sobre o investimento (ROI) e que sejam viáveis de implementar.

1.2.2 1.2.2 IA Responsável

Estamos comprometidos com o desenvolvimento e a implantação de sistemas de IA que sejam éticos, justos, transparentes e seguros. Nossas soluções devem ser projetadas para minimizar vieses, proteger a privacidade dos dados e ser compreensíveis para os stakeholders.

1.2.3 1.2.3 Excelência Técnica e Operacional

Buscamos a excelência em todo o ciclo de vida do projeto, desde o desenho da arquitetura até a implantação e monitoramento. Adotamos padrões de MLOps/LLMOps para criar soluções robustas, escaláveis e de fácil manutenção.

2.1.1 2.1.1 Nível 1: Inicial

Características: Adoção de IA inexistente ou limitada a esforços isolados e não documentados. A cultura de dados é fraca, e os dados são frequentemente armazenados em silos, com baixa qualidade e difícil acesso. Não há talentos especializados em IA ou ciência de dados. As decisões são tomadas com base na intuição, não em dados.

Foco da Consultoria: Evangelização sobre o potencial da IA, identificação de "quick wins" e início da jornada de aculturação de dados.

2.1.2 2.1.2 Nível 2: Emergente

Características: Primeiras provas de conceito (PoCs) de IA são iniciadas, geralmente em áreas específicas e de forma experimental. Há uma consciência crescente sobre a importância dos dados, com esforços iniciais para centralizá-los e limpá-los. Equipes pequenas e dedicadas começam a se formar.

Foco da Consultoria: Estruturação de projetos piloto, definição de uma estratégia de dados formal e capacitação das equipes técnicas iniciais.

2.1.3 2.1.3 Nível 3: Competente

Características: A IA está integrada em processos de negócio chave, gerando valor comprovado. A governança de dados é uma prática estabelecida. A infraestrutura de nuvem e as plataformas de MLOps/LLMOps são utilizadas para escalar as soluções. As equipes de IA são multidisciplinares e colaboram com as áreas de negócio.

Foco da Consultoria: Otimização e escalonamento das soluções existentes, fortalecimento da governança e expansão da cultura de IA para toda a organização.

2.1.4 2.1.4 Nível 4: Líder

Características: A IA é um pilar central da estratégia de negócio, impulsionando a inovação e a vantagem competitiva. O acesso a dados e ferramentas de IA é democratizado. Ciclos de inovação são rápidos, com re-treinamento e melhoria contínua de modelos. A IA Responsável é uma prática auditável e integrada em todo o ciclo de vida.

Foco da Consultoria: Co-criação de novas frentes de inovação, exploração de tecnologias de ponta e otimização do ROI em escala.

2.2.1 2.2.1 Pilar 1 — Negócio

Objetivo: Entender o alinhamento estratégico da IA com os objetivos da empresa.

Exemplos de tópicos avaliados: - Existe um executivo (C-level) patrocinando a estratégia de IA? - Os casos de uso de IA estão claramente ligados a KPIs de negócio? - Como a concorrência está utilizando IA? - Existe um comitê de ética para supervisionar as iniciativas de IA?

2.2.2 2.2.2 Pilar 2 — Dados

Objetivo: Avaliar a qualidade, disponibilidade e governança dos ativos de dados.

Exemplos de tópicos avaliados: - Os dados críticos para o negócio estão centralizados em um Data Lake ou Lakehouse? - Qual é o processo para garantir a qualidade e a linhagem dos dados? - A organização possui uma estratégia para dados não estruturados (texto, imagens, etc.)? - A Lei Geral de Proteção de Dados (LGPD) é aplicada na gestão de dados?

2.2.3 2.2.3 Pilar 3 — Infraestrutura e Tecnologia

Objetivo: Mapear a prontidão da arquitetura tecnológica para suportar o ciclo de vida da IA.

Exemplos de tópicos avaliados: - Qual provedor de nuvem é utilizado e qual a maturidade de seu uso? - Existe uma plataforma de MLOps/LLMOps para automação de deploy e monitoramento? - Como é feita a gestão de segredos e chaves de API para serviços de IA? - A capacidade computacional (GPUs) é adequada para os casos de uso planejados?

2.2.4 2.2.4 Pilar 4 — Pessoas e Cultura

Objetivo: Analisar as habilidades da equipe e a cultura organizacional para a adoção da IA.

Exemplos de tópicos avaliados: - Quais são os papéis e responsabilidades das equipes de dados e IA? - Existe um plano de capacitação e contratação para talentos de IA? - A cultura da empresa incentiva a experimentação e aceita o erro como parte do processo de inovação? - Como as áreas de negócio e tecnologia colaboram em projetos de IA?

Fluxo de Engajamento do Cliente

• Pré-Engajamento — Contato Inicial e Qualificação: Primeiro ponto de contato. Entendimento do interesse, desafios em alto nível e qualificação da oportunidade. Saída: Decisão de avançar (Go/No-Go) para Workshop.
• Workshop de Descoberta: Reunião aprofundada com stakeholders (negócio e técnico) para entender problemas, requisitos, dados e critérios de sucesso. Saída: Entendimento claro do escopo e requisitos.
• Desenho e Apresentação da Proposta: Elaboração da proposta técnica e comercial baseada no workshop de descoberta. Apresentação para decisão do cliente. Saída: Proposta Comercial e Técnica formalizada.

Checklist da Fase 1

Itens Obrigatórios: - [ ] Definição do Problema de Negócio: Problema claramente definido e quantificado em valor? - [ ] Identificação dos Stakeholders: Principais interessados (patrocinadores, usuários, equipe) identificados? - [ ] Critérios de Sucesso: Como o sucesso será medido (KPIs de negócio, métricas de adoção)?

Itens Recomendados: - [ ] Análise de Viabilidade: Solução viável com tecnologia, dados e orçamento? ROI justificado? - [ ] Escopo Inicial (MVP): Um escopo mínimo viável (MVP) definido para a primeira entrega de valor?

Fluxo de Engajamento do Cliente

• Kick-off e Alinhamento: Reunião com a equipe do projeto (cliente e consultoria) para alinhar objetivos, responsabilidades e processos de trabalho. Saída: Equipe alinhada e motivada.
• Desenho da Solução Detalhado: Colaboração para detalhar a arquitetura da solução, incluindo tecnologia, dados e experiência do usuário. Saída: Arquitetura da Solução e Desenho de UX/UI.
• Definição do Roadmap: Criação do plano de implementação, com etapas claras, marcos e prazos, focando em entregas iterativas de valor. Saída: Roadmap do Projeto e Cronograma.

Atividade Central — Pilha de IA de 5 Camadas

Utilizamos nosso framework da "Pilha de IA de 5 Camadas" para desenhar uma arquitetura robusta e apresentar ao cliente de forma clara:

1. Infraestrutura: Definição da base computacional. Onde a solução rodará (AWS, Azure, GCP, On-premise)? Qual a necessidade de hardware (GPU vs. CPU)?
2. Modelos: Seleção dos modelos de IA. Usaremos um LLM ou um SLM? Será um modelo open-source (ex: Llama 3) ou proprietário (ex: GPT-4, Claude 3)? A solução exige fine-tuning?
3. Dados: Estratégia de contextualização dos modelos. De onde virão os dados (fontes internas, externas)? Como serão processados (Pipelines de ETL/ELT)? Utilizaremos uma abordagem de RAG com Vector Databases?
4. Orquestração: Definição da lógica de negócio e do "cérebro" da aplicação de IA. Como o sistema irá planejar e executar tarefas? Como ele irá interagir com outras ferramentas e APIs (Tool Calling)?
5. Aplicação: A camada de interação com o usuário final. Será uma API, um chatbot, uma nova interface de usuário (UI) ou uma integração com um sistema existente?

Checklist da Fase 2

Itens Obrigatórios: - [ ] Definição da Abordagem de IA: Qual tipo de IA será usado (ML customizado, GenAI, Copilot, Agentes)? - [ ] Mapeamento de Recursos e Dependências: Dados, sistemas, APIs e ferramentas necessárias mapeadas e acessíveis? - [ ] Desenho da Experiência do Usuário (UX): Interação do usuário final com a solução desenhada? - [ ] Definição de Requisitos Não Funcionais: Requisitos de segurança, privacidade, latência, escalabilidade e conformidade documentados?

Itens Recomendados: - [ ] Prova de Conceito (PoC): Uma PoC desenvolvida para validar a principal hipótese técnica com esforço mínimo? - [ ] Análise de Riscos: Principais riscos identificados e planos de mitigação criados (técnicos, de negócio, éticos)?

Fluxo de Engajamento do Cliente

• Sprints de Desenvolvimento: Colaboração contínua do cliente nos ciclos de desenvolvimento (sprints), com reuniões de revisão e feedback regulares. Saída: Entregas incrementais de funcionalidades.
• Validação com Usuários (UAT): Testes da solução por parte dos usuários finais do cliente para garantir que atende às suas necessidades e expectativas. Saída: Aprovação da solução pelos usuários.
• Revisão de Implantação: Planejamento e aprovação da estratégia de implantação da solução em ambiente de produção. Saída: Estratégia de Deploy definida e aprovada.

Checklist da Fase 3

Itens Obrigatórios: - [ ] Setup do Ambiente: Ambientes (desenvolvimento, testes, produção) configurados e provisionados via código (IaC)? - [ ] Implementação do Core da Solução: Desenvolvimento da lógica principal (pipelines, modelos, prompts, bots) iniciado? - [ ] Teste End-to-End (E2E): O fluxo completo da solução testado (da entrada do usuário à saída final)? - [ ] User Acceptance Testing (UAT): Solução validada pelos usuários finais? - [ ] Estratégia de Implantação (Deploy): Estratégia para produção definida (Canary, Blue/Green, etc.)?

Itens Recomendados: - [ ] Práticas de Código e CI: Código versionado (Git) e processo de Integração Contínua (CI) em vigor? - [ ] Métricas de Avaliação Específicas: Métricas relevantes para o tipo de projeto avaliadas (acurácia, RAGAs, sucesso de tarefa)? - [ ] Análise de IA Responsável: Solução avaliada quanto a vieses, equidade, explicabilidade e privacidade? - [ ] Criação de "Model Card": Criado para modelos de ML/GenAI (propósito, performance, limitações)? - [ ] Pipeline de CI/CD (e CT): Pipeline para automatizar integração, deploy e (se aplicável) treinamento contínuo implementado?

Fluxo de Engajamento do Cliente

• Monitoramento e Suporte: Monitoramento contínuo da solução em produção e suporte técnico para garantir a estabilidade e performance. Saída: Relatórios de Performance e Suporte contínuo.
• Coleta de Feedback e Otimização: Processo estruturado para coletar feedback dos usuários e identificar oportunidades de melhoria e novas funcionalidades. Saída: Plano de Melhoria Contínua e Novas Features.
• Revisões Periódicas de Valor: Reuniões periódicas para avaliar o impacto da solução nos KPIs de negócio e discutir a evolução da estratégia de IA. Saída: Alinhamento Estratégico e Otimização de ROI.

Checklist da Fase 4

Itens Obrigatórios: - [ ] Monitoramento da Saúde da Aplicação: Saúde da infraestrutura e da aplicação monitorada (CPU, memória, latência, erros)? - [ ] Monitoramento da Qualidade da IA: Performance do componente de IA monitorada em produção (drift, alucinações, sucesso do Copilot)? - [ ] Plano de Sustentação e Melhoria: Plano para corrigir bugs, fazer melhorias e retreinar modelos (se aplicável) definido?

Itens Recomendados: - [ ] Dashboard de Acompanhamento de KPIs: Dashboard criado para stakeholders acompanharem o impacto nos KPIs de negócio? - [ ] Mecanismo de Coleta de Feedback do Usuário: Processo para coletar, analisar e priorizar feedback dos usuários finais estabelecido?

4.1.1 4.1.1 Versionamento Unificado

Em projetos de IA, não basta versionar o código. Um modelo é o resultado de código, dados e configuração. Portanto, nosso padrão de versionamento exige:

• Versionamento de Código (Git): Todo o código-fonte, incluindo scripts de treino, pré-processamento e APIs, é versionado no Git.
• Versionamento de Dados (DVC, Lakehouse): Os conjuntos de dados de treino, teste e validação são versionados. Ferramentas como DVC (Data Version Control) ou o time travel de plataformas como Databricks/Snowflake são usadas para garantir que possamos reconstruir um modelo com os dados exatos com os quais ele foi treinado.
• Versionamento de Modelos (Model Registry): Os artefatos de modelo treinados são armazenados em um "Model Registry" (ex: MLflow, Azure ML Registry), que versiona o binário do modelo e o associa às versões do código e dos dados que o geraram.

4.1.2 4.1.2 CI/CD para IA (Continuous Integration / Continuous Deployment)

Nossas esteiras de automação (CI/CD) vão além da compilação e do deploy de aplicações tradicionais. Elas orquestram o ciclo de vida completo do modelo.

CI — Integração Contínua: A cada git push, a esteira de CI é acionada para: 1. Linting e Análise Estática: Garantir a qualidade do código. 2. Testes Unitários: Validar a lógica de componentes individuais. 3. (Opcional) Treinamento do Modelo: Em um ambiente de teste, a esteira pode re-treinar o modelo para validar que as mudanças no código não quebraram o processo de treino. 4. Testes de Contrato e Integração: Garantir que as interfaces do modelo (APIs) não foram alteradas de forma inesperada.

CD — Implantação Contínua: Uma vez que um modelo é aprovado (seja por um git tag ou por promoção manual no Model Registry), a esteira de CD é responsável por: 1. Provisionamento de Infraestrutura (IaC): Usar Terraform ou Bicep para criar a infraestrutura de serviço (ex: Azure Machine Learning Endpoint). 2. Deploy do Modelo: Implantar o modelo versionado do Model Registry no ambiente de produção. 3. Testes de Fumaça (Smoke Tests): Realizar testes básicos no endpoint em produção para garantir que ele está respondendo. 4. Implantação Gradual (Canary/Blue-Green): Liberar o novo modelo para uma pequena porcentagem de usuários antes de direcionar 100% do tráfego, monitorando por erros ou degradação de performance.

4.1.3 4.1.3 Monitoramento

Após o deploy, o trabalho não termina. O monitoramento contínuo é essencial para garantir a saúde da solução:

• Monitoramento de Infraestrutura: Uptime, latência, utilização de CPU/GPU.
• Data Drift: Mudanças na distribuição estatística dos dados de entrada, que podem degradar a performance do modelo.
• Model Drift (Concept Drift): Mudanças na relação entre os dados de entrada e a saída esperada, indicando que o modelo não representa mais a realidade.
• Monitoramento de Custo: Acompanhamento dos custos de inferência e infraestrutura para garantir que a solução permaneça dentro do orçamento.

4.2.1 4.2.1 RAG (Retrieval-Augmented Generation)

O RAG é o padrão mais comum e, geralmente, o ponto de partida para aplicações de "chat com seus dados". Ele "aumenta" o conhecimento de um LLM com informações externas e específicas do seu domínio, sem a necessidade de re-treinamento.

Fase de Ingestão (Offline):

• Load & Chunk: Seus documentos (PDFs, DOCs, etc.) são carregados e quebrados em pedaços menores (chunks). A estratégia de "chunking" é crucial para a qualidade do resultado.
• Embedding: Cada "chunk" é transformado em uma representação numérica (um vetor) por um modelo de embedding. Este vetor captura o significado semântico do texto.
• Store: Os vetores e o texto original são armazenados em um Banco de Dados Vetorial (Vector Database), como Azure AI Search, Pinecone ou ChromaDB.

Fase de Inferência (Online/Real-time):

• Query: O usuário faz uma pergunta.
• Embedding da Query: A pergunta do usuário também é transformada em um vetor pelo mesmo modelo de embedding.
• Retrieve (Busca): O sistema busca no Banco de Dados Vetorial os "chunks" de texto cujos vetores são mais próximos (semanticamente similares) ao vetor da pergunta.
• Augment (Aumentar): Os "chunks" recuperados são inseridos no prompt que será enviado ao LLM, junto com a pergunta original do usuário.
• Generate: O LLM gera uma resposta baseada no contexto fornecido, o que reduz drasticamente as "alucinações" e garante que a resposta seja fundamentada nos seus dados.

Quando usar RAG: - Quando você precisa que o LLM responda com base em um corpo de conhecimento específico e mutável (ex: documentos internos, base de conhecimento, etc.). - Quando a rastreabilidade é importante (você pode citar as fontes usadas para a resposta). - Quando você quer evitar o custo e a complexidade de um fine-tuning.

4.2.2 4.2.2 Fine-Tuning (Ajuste Fino)

O Fine-Tuning é o processo de pegar um LLM pré-treinado e continuar seu treinamento em um conjunto de dados menor e específico. O objetivo não é ensinar novo conhecimento ao modelo, mas sim ajustar seu comportamento, estilo ou formato de resposta.

Como Funciona: 1. Preparação do Dataset: Você cria um conjunto de dados de alta qualidade no formato de pares prompt/resposta_ideal. 2. Processo de Treinamento: Você utiliza a API de um provedor de modelos (como Azure OpenAI ou Google Vertex AI) ou frameworks de código aberto (como a biblioteca transformers da Hugging Face) para executar o processo de fine-tuning. 3. Deploy e Inferência: Você faz o deploy deste novo modelo customizado e o utiliza para inferência.

Quando usar Fine-Tuning: - Para adaptar o estilo, tom ou formato de um modelo. (Ex: "Quero que o modelo sempre responda em formato JSON"). - Para ensinar ao modelo uma nova habilidade ou tarefa que é difícil de explicar em um prompt. - NÃO é a melhor abordagem para injetar conhecimento factual. Para isso, RAG é mais eficiente e escalável.

4.2.3 4.2.3 RAG vs. Fine-Tuning — Qual Escolher?

Regra geral: Comece sempre com RAG. Se, e somente se, o RAG não for suficiente para atingir o comportamento desejado, considere adicionar o Fine-Tuning como uma otimização. Muitas vezes, a melhor solução é uma combinação de ambos.

4.3.1 4.3.1 Novas Vulnerabilidades em Sistemas de IA

• Injeção de Prompt (Prompt Injection): Esta é a vulnerabilidade mais crítica e comum. Ocorre quando um usuário malicioso insere instruções no prompt que subvertem as instruções originais do sistema.
• Vazamento de Dados Sensíveis (Data Leakage): O LLM pode, inadvertidamente, revelar informações sensíveis que foram incluídas em seu contexto (via RAG) ou em seus dados de treinamento.
• Ataques de Negação de Serviço (DoS): Usuários podem criar prompts complexos e recursivos que consomem uma quantidade excessiva de recursos computacionais (tokens), levando a custos altos ou à indisponibilidade do serviço.
• Geração de Conteúdo Nocivo: O modelo pode ser manipulado para gerar desinformação, discurso de ódio ou outro conteúdo inseguro.

4.3.2 4.3.2 Nossa Estratégia de Defesa

Nossa abordagem de segurança em IA é proativa e baseada em múltiplas camadas de defesa.

Red Teaming para IA: O "Red Teaming" é um processo de teste de segurança adversário, onde uma equipe ("time vermelho") simula ataques para encontrar vulnerabilidades antes que atores maliciosos o façam. Nossos especialistas em segurança de IA tentam ativamente "quebrar" o sistema de IA, utilizando uma vasta gama de técnicas de injeção de prompt, tentando extrair dados sensíveis e testando os limites dos filtros de segurança. O objetivo é identificar as fraquezas no prompt do sistema, nas configurações dos modelos e no fluxo de dados, para que possam ser corrigidas antes do deploy.

Validação e Sanitização de Entradas e Saídas: Sanitização de Entradas — nunca confiamos diretamente na entrada do usuário. Implementamos camadas de validação para detectar e neutralizar padrões maliciosos conhecidos antes que eles cheguem ao LLM. Monitoramento de Saídas — a resposta do LLM também é monitorada. Filtros são aplicados para garantir que o modelo não esteja gerando conteúdo nocivo ou vazando informações que se pareçam com dados sensíveis (ex: números de cartão de crédito, CPFs).

Técnicas de Prompt Engineering para Segurança: - Instruções Claras: O prompt do sistema deve ser extremamente claro sobre o que o modelo pode e, mais importante, o que ele não pode fazer. - Delimitadores: Usamos delimitadores para separar claramente as instruções do sistema dos dados fornecidos pelo usuário. - "Instruction Priming": Repetimos as instruções de segurança mais críticas no final do prompt para reforçar seu comportamento esperado.

Ciclo de Vida de Segurança Contínua: A segurança de IA não é um evento único, mas um ciclo contínuo: Testar → Corrigir → Monitorar → Adaptar.

4.4.1 4.4.1 O Princípio: Nunca Armazene Segredos em Código

A regra fundamental é: segredos nunca devem ser armazenados diretamente no código-fonte ou em arquivos de configuração versionados no Git.

4.4.2 4.4.2 Padrão de Arquitetura — O Cofre de Segredos (Secrets Vault)

A melhor prática é centralizar a gestão de segredos em um serviço especializado (ex: Azure Key Vault, AWS Secrets Manager, HashiCorp Vault).

Fluxo de Acesso Seguro em Aplicações de IA:

1. Identidade Gerenciada: A aplicação recebe uma "identidade" do provedor de nuvem.
2. Política de Acesso: No Cofre, a identidade da aplicação recebe permissão para LER segredos específicos.
3. Recuperação em Tempo de Execução: A aplicação se autentica usando sua identidade, solicita o segredo e o recebe em memória.
4. Uso em Memória: O segredo é usado para se conectar ao serviço de IA e nunca é escrito em disco ou em logs.

Benefícios desta Abordagem: Zero Segredos no Código; Gestão Centralizada; Segurança Máxima.

4.5.1 4.5.1 O que é uma Ficha de Modelo?

É um "documento de identidade" para um modelo de IA, que fornece informações claras sobre seu treino, performance, limitações e uso pretendido.

4.5.2 4.5.2 Por que é Essencial?

• Rastreabilidade e Reprodutibilidade.
• Governança e Conformidade (Compliance).
• Comunicação com Stakeholders.
• Mitigação de Riscos de IA Responsável.

4.5.3 4.5.3 Nossa Estrutura Padrão de Model Card

• Detalhes do Modelo: Nome, versão, tipo, desenvolvedores.
• Uso Pretendido: Caso de uso primário e cenários fora do escopo.
• Dados de Treinamento e Avaliação: Fontes, período, processamento.
• Métricas de Performance: Métricas de avaliação e resultados quantitativos.
• Considerações Éticas e Limitações: Análise de viés, limitações conhecidas.
• Rastreabilidade: Links para o código-fonte, dados e ambiente.

Este artefato é gerado ao final da Fase 3 (Implementação) e é mantido e atualizado durante a Fase 4 (Operação).

5.1.1 5.1.1 Métricas de Negócio (KPIs)

Essas métricas medem o impacto da solução de IA nos objetivos de negócio. Elas respondem à pergunta: "Por que estamos fazendo isso?".

5.1.2 5.1.2 Métricas Técnicas (SLOs) — ML Clássico

Medem a qualidade e a performance de modelos de previsão, classificação e outros algoritmos de ML clássico.

5.1.3 5.1.3 Métricas Técnicas (SLOs) — IA Generativa (GenAI)

Medem a qualidade, custo e segurança de soluções baseadas em LLMs, como RAG e chatbots.

Agenda Padrão da QBR

1. Revisão do Valor de Negócio: Apresentar o dashboard de KPIs de Negócio. O projeto atingiu as metas de ROI definidas na Fase 1?
2. Revisão da Performance Operacional e Custo: Apresentar o dashboard de SLOs técnicos (Latência, Drift, Custo). A solução está estável? Os custos estão dentro do orçamento?
3. Revisão de IA Responsável e Segurança: Relatório de incidentes de segurança, problemas de viés detectados ou feedback de usuários sobre respostas problemáticas.
4. Feedback do Usuário Final: Apresentar feedback qualitativo dos usuários.
5. Roadmap e Próximos Passos: Com base em tudo acima, o que faremos no próximo trimestre? Opções: Manter, Otimizar Custos, Retreinar Modelo, Expandir para um Novo Caso de Uso.

5.3.1 5.3.1 Conformidade Regulatória (LGPD)

• Anonimização de Logs: Garantir que os logs de inferência (perguntas dos usuários, dados de entrada) estejam anonimizados ou tenham um TTL (Time-to-Live) curto para proteger a privacidade.
• Governança de Dados de Treino: Ter processos para lidar com solicitações de "direito ao esquecimento" (LGPD), removendo dados de usuários dos próximos ciclos de retreinamento.
• Auditoria: Manter a Ficha de Modelo (Model Card) atualizada como o principal documento de conformidade para auditorias regulatórias.

5.3.2 5.3.2 IA Responsável (RAI) Operacional

Monitoramento Ativo de Viés: Para modelos de Data Science (ex: crédito, RH), os dashboards DEVEM monitorar se a performance do modelo está degradando para subgrupos específicos (viés de performance).

Monitoramento de Segurança de GenAI: Alertas (em tempo real, se possível) para picos em: Tentativas de Prompt Injection detectadas; Respostas bloqueadas por filtros de toxicidade; Tópicos sensíveis sendo discutidos.

Processo de Escalada e Incidente RAI: O Runbook DEVE conter um capítulo para "Incidentes de IA Responsável". Exemplo — se o modelo vazar dados confidenciais ou gerar conteúdo ilegal: tirar o endpoint do ar (se necessário); escalar para o Líder Técnico e o Comitê de Ética do cliente; analisar a causa raiz (ex: um prompt injection bem-sucedido); aplicar correção (ex: melhorar o prompt de sistema, atualizar filtros); documentar na Ficha de Modelo e no relatório de QBR.

6.4.1 6.4.1 Nível 1: Inicial (Initial)

Foco: Exploração básica de LLMs pré-construídos.

Características: Uso de modelos como o GPT-3 para prototipagem rápida, com processos manuais e pouca ou nenhuma automação. A implantação é ad-hoc.

Perspectiva FinOps: Custos são exploratórios e muitas vezes imprevisíveis. O foco está em experimentar e aprender, sem uma otimização de custos rigorosa.

6.4.2 6.4.2 Nível 2: Definido (Defined)

Foco: Construção de soluções mais robustas com engenharia de prompts e talvez alguns modelos de fine-tuning.

Características: Processos de desenvolvimento e implantação mais estruturados. Início da automação de pipelines e versionamento de código e prompts.

Perspectiva FinOps: Começa a haver uma previsibilidade de custos. As equipes começam a monitorar os gastos e a identificar oportunidades básicas de otimização.

6.4.3 6.4.3 Nível 3: Gerenciado (Managed)

Foco: Implementação de sistemas de ponta a ponta com automação e monitoramento contínuos.

Características: Pipelines de CI/CD para modelos e aplicações, monitoramento de desempenho e de desvio de dados (data drift), e estratégias de A/B testing.

Perspectiva FinOps: Gestão de custos proativa. O uso de dashboards de custos é comum, e as equipes otimizam ativamente os recursos, escolhendo os modelos e a infraestrutura mais eficientes em termos de custo-benefício.

6.4.4 6.4.4 Nível 4: Otimizado (Optimized)

Foco: Melhoria contínua e iterativa do sistema com base em feedback em tempo real.

Características: Sistemas totalmente automatizados com auto-recuperação e otimização contínua de modelos (por exemplo, re-treinamento automático). Uso de MLOps avançado para governança e segurança.

Perspectiva FinOps: Os custos são totalmente otimizados e alinhados com o valor de negócio. A alocação de custos é precisa, e as decisões de investimento em IA são baseadas em análises de ROI detalhadas.

A progressão através desses níveis permite que as organizações implementem e escalem aplicações de LLM de forma eficaz, garantindo tanto a sofisticação técnica quanto a sustentabilidade financeira.

7.1.1 7.1.1 Architecture Decision Record (ADR)

Um Architecture Decision Record (ADR) é um documento que captura uma decisão arquitetural importante feita ao longo do tempo em um projeto de software.

• Status: Recomendado
• Quando usar: Ao tomar uma decisão de arquitetura significativa que terá impacto no sistema.

Template ADR:

# Título do ADR

- **Status:** Proposto | Aceito | Depreciado | Substituído
- **Data:** YYYY-MM-DD

## Contexto
Descrição do problema ou da força motriz por trás desta decisão.

## Decisão
A mudança que estamos propondo e o raciocínio por trás dela.

## Consequências
O que se torna mais fácil ou mais difícil de fazer por causa dessa mudança.

7.1.2 7.1.2 Diagrama de Arquitetura C4

O modelo C4 para visualização de arquitetura de software fornece um conjunto de abstrações para descrever um sistema de software em diferentes níveis de detalhe.

• Nível 1 — Contexto: Mostra o sistema em escopo e suas relações com usuários e outros sistemas.
• Nível 2 — Contêineres: Decompõe o sistema em contêineres (aplicativos, bancos de dados, etc.).
• Nível 3 — Componentes: Decompõe os contêineres em componentes.
• Nível 4 — Código: Um olhar mais atento sobre os componentes, mostrando como são implementados.

7.2.1 7.2.1 Post-mortem

Um post-mortem é um processo para analisar um incidente (como uma falha de produção) para entender a causa raiz e evitar que aconteça novamente.

• Quando usar: Após a resolução de um incidente significativo.

Template Post-mortem:

# Post-mortem: [Nome do Incidente]

- **Data:** YYYY-MM-DD
- **Autores:** [Nomes]
- **Status:** Rascunho | Em Revisão | Final

## Resumo
Breve descrição do incidente, seu impacto e a duração.

## Linha do Tempo
Uma linha do tempo detalhada dos eventos durante o incidente.

## Causa Raiz
Análise da(s) causa(s) raiz do incidente.

## Ações Corretivas
Lista de ações para prevenir a recorrência do problema.

7.2.2 7.2.2 Request for Comments (RFC)

Um Request for Comments (RFC) é um documento para propor e obter feedback sobre uma mudança técnica ou de processo.

• Quando usar: Ao propor uma nova feature, mudança de arquitetura ou alteração em um processo de equipe.

Template RFC:

# RFC: [Título da Proposta]

- **Status:** Rascunho | Em Discussão | Aprovado | Rejeitado
- **Autor:** [Nome]
- **Data:** YYYY-MM-DD

## Resumo
Uma breve descrição da proposta.

## Motivação
Por que esta mudança é necessária? Qual problema ela resolve?

## Proposta Detalhada
Descrição detalhada da mudança proposta.

## Alternativas Consideradas
Quais outras soluções foram consideradas e por que foram descartadas.

7.3.1 7.3.1 Nomenclatura de Repositórios e Projetos

• Nome do Repositório: Deve seguir o padrão kebab-case — apenas letras minúsculas, números e hífens simples como separador (ex: repo-provisioner, client-onboarding-api). Nomes com espaços, underscores, letras maiúsculas ou acentuação são automaticamente normalizados para este padrão.
• Prefixo de Tipo de Projeto: Todo repositório deve indicar seu tipo — IA (e Data Agents) ou Automação — em algum ponto do nome informado (ex: Chatbot IA Suporte, RPA Automação Financeiro, ia-chatbot-suporte). A automação de provisionamento identifica a palavra ia ou automacao (sem acento, sem diferenciar maiúsculas/minúsculas) onde quer que ela apareça no nome e a move sempre para o prefixo do nome final (ex: ia-chatbot-suporte, automacao-rpa-financeiro), usando esse prefixo para decidir qual scaffold aplicar (Seção 7.3.5). Repositórios em que nenhuma das duas palavras aparece recebem o Scaffold Genérico (Seção 7.3.5.3).
• Código do Projeto (Azure DevOps): Deve ser um acrônimo em letras maiúsculas, de 2 a 6 caracteres (ex: AI, SOLO, MLOPS), usado para agrupar repositórios relacionados a uma mesma iniciativa ou cliente.
• Nome da Organização (GitHub): Repositórios no GitHub seguem a mesma convenção kebab-case, prefixados pelo nome do time ou produto quando aplicável (ex: ai-consulting-playbook).

7.3.2 7.3.2 Estratégia de Branches

Adotamos o modelo GitHub Flow (trunk-based, simplificado) como padrão para a maioria dos projetos, salvo indicação contrária no desenho da solução:

• main: Branch protegida, sempre "deployável". Nenhum commit direto é permitido — toda mudança entra via Pull Request.
• feature/<descrição-curta>: Para novas funcionalidades (ex: feature/add-rag-endpoint).
• fix/<descrição-curta>: Para correções de bugs (ex: fix/token-expiration).
• release/<versão>: Opcional, usada apenas em projetos com ciclos de release formais e necessidade de estabilização antes do deploy.

7.3.3 7.3.3 Políticas de Pull Request e Branch Protection

Independentemente da plataforma, toda branch main deve ter as seguintes políticas ativas:

7.3.4 7.3.4 Convenção de Commits Semânticos

Todo commit deve seguir o padrão de Commits Semânticos (ver também Seção 9.4):

<tipo>: <descrição curta no imperativo>

[corpo opcional explicando o porquê]

Tipos permitidos: feat (nova funcionalidade), fix (correção de bug), docs (documentação), chore (manutenção, sem impacto em código de produção), refactor, test.

7.3.5 7.3.5 Estrutura Inicial Obrigatória (Scaffold)

Todo repositório novo deve nascer com um pacote mínimo de arquivos — aplicado automaticamente pela automação de provisionamento. O pacote varia conforme o tipo de projeto, identificado pelo prefixo do nome do repositório (Seção 7.3.1).

7.4.1 7.4.1 Convenção de Pastas

Cada projeto organiza seus artefatos de fase em docs/, seguindo kebab-case (Seção 7.3.1):

• docs/fase-1-planejamento/
• docs/fase-2-execucao/
• docs/fase-3-pos-deploy/

7.4.2 7.4.2 Tipos de Validação

7.4.3 7.4.3 Fase 1 — Planejar e Validar

7.4.4 7.4.4 Fase 2 — Executar e Validar

7.4.5 7.4.5 Fase 3 — Pós-Deploy e Melhorias da Garantia

Nota: os caminhos de arquivo e o tipo de validação (arquivo/work-item/pull-request/manual) foram definidos por esta automação a partir da planilha de origem, que descreve os artefatos e responsáveis mas não define caminhos de repositório. Ajuste esta tabela antes de usá-la como contrato de validação, caso a convenção real do time seja diferente. Artefatos do tipo arquivo são materializados no repositório como uma pasta (nome derivado do caminho indicado, sem a extensão) contendo um README.md inicial — não como um arquivo solto — para comportar múltiplas evidências por etapa (exceto o README.md da raiz do repositório, que permanece um arquivo).

7.5.1 7.5.1 Fase 1 — Planejar e Validar

7.5.2 7.5.2 Fase 2 — Executar e Validar

7.5.3 7.5.3 Fase 3 — Pós-Deploy e Melhorias da Garantia

Nota: assim como na Seção 7.4, os caminhos de arquivo e o tipo de validação foram definidos por esta automação a partir da planilha de origem (aba PROCESSOS_AREA_AUTOMACAO), que descreve os artefatos e responsáveis mas não define caminhos de repositório — ajuste esta tabela antes de usá-la como contrato de validação, caso a convenção real do time seja diferente. Dois itens da planilha de origem ("Análise dos Defeitos" e "Consolidação da Documentação Final") vieram com Responsável/Revisor referenciando "QA IA"/"Especialista de IA" — aparente resíduo de cópia da aba de IA — e foram normalizados aqui para "QA"/"Especialista de Automação"; confirme com quem preencheu a planilha se a intenção era outra.