---
title: "Governança de IA no desenvolvimento de software"
description: "Quando o time programa com IA, a governança está no caminho até produção, não no modelo: três camadas e um trilho estreito, igual para pessoa e máquina."
url: https://franklinfreitas.com/blog/governanca-de-ia-caminho-estreito-ate-producao
---

[Blog](https://franklinfreitas.com/blog/) [Governança de IA](https://franklinfreitas.com/blog/governanca-de-ia/) Governança de IA no código: o caminho estreito até produção

Governança de IA · 28 de agosto de 2026 · 18 min de leitura

# Governança de IA no código: o caminho estreito até produção

Governança de IA no desenvolvimento não é escolher o modelo certo. É estreitar o caminho até produção, em três camadas: o que o assistente pode fazer na máquina de quem programa, que dados ele alcança e por onde o código chega ao servidor. Só passa o que foi revisado, testado e verificado, venha de uma pessoa ou da IA.

## Em resumo

- A escolha do modelo é a decisão menos importante: qualquer modelo escreve código errado com toda a confiança.
- Com IA, o time produz mais código, mais rápido, com o mesmo número de pessoas para revisar. É a revisão que não escala.
- Três camadas, de quem digita até o servidor: quem usa a IA, o que a IA alcança e por onde o código chega.
- Controle é mecanismo, não boa vontade. Cada um responde a três perguntas: o que barra, como se prova que barra e o que acontece quando falha.
- O caminho estreito é um só, igual para pessoa e máquina, e bloqueia em vez de alertar. Às pessoas ficam a revisão, o risco aceito e o botão de desligar.

## Por que a pergunta "qual IA usar?" é a menos importante?

Porque qualquer modelo, de qualquer fornecedor, escreve código errado com toda a confiança, e trocar de modelo não muda o que acontece com esse código depois. A escolha do assistente, do plano e do modelo costuma ocupar a maior parte das reuniões sobre IA no desenvolvimento, e é a decisão que menos mexe no risco. O risco está no trecho entre o que a IA escreve e o que chega ao servidor: quem olhou, o que foi testado, o que foi barrado e por onde aquilo passou.

Há um dado público que ajuda a desfazer a ideia de que o modelo certo resolve. Em julho de 2025, a Veracode publicou um teste com 80 tarefas de programação desenhadas para expor fraquezas conhecidas, aplicado a mais de 100 modelos de linguagem. Quando a tarefa admitia um jeito seguro e um inseguro, os modelos escolheram o inseguro em 45% dos casos, e os maiores não se saíram significativamente melhor que os menores. O teste foi construído para provocar o erro, então o número não descreve o código que um time escreve no dia a dia. O que ele mostra é outra coisa: tamanho e versão do modelo não são um controle.

Por isso, quando a conversa começa em "qual IA o time deve usar?", nós a puxamos para três perguntas que continuam valendo depois da próxima troca de modelo. O que o assistente pode fazer na máquina de quem programa? Que dados e sistemas ele alcança? Por qual caminho o código que ele ajudou a escrever vira produção? Esta série responde às três, uma camada por vez, e este texto é o mapa.

Em uma frase

Governança de IA no desenvolvimento: O conjunto de mecanismos que define o que um assistente de IA pode fazer na máquina de quem programa, que dados ele alcança e por qual caminho verificável o código que ele ajudou a escrever chega a produção.

Repare no que a definição deixa de fora: o modelo. Ele entra como peça trocável. Se a governança dependesse do modelo em uso, cada versão nova seria uma reavaliação de todo o risco do time. Com o caminho no lugar, trocar de modelo é trocar uma peça e observar se os mesmos controles continuam barrando o que devem barrar.

## O que muda quando o código passa a ser escrito com IA?

Muda a proporção entre quem escreve e quem revisa. Com IA, o time produz mais código, mais rápido, com o mesmo número de pessoas para revisar, e esse código chega com uma aparência de acabamento que desarma quem lê. Quatro coisas mudam ao mesmo tempo, e só uma delas é a que todo mundo comenta.

O que mudaComo aparece no dia a diaPor que pesa na governançaVolumeUma pessoa com um assistente entrega numa tarde o que levava dias. Os pedidos de alteração ficam maiores e mais frequentes.A fila de revisão cresce na mesma proporção, e o revisor continua sendo uma pessoa.VelocidadeO tempo entre a ideia e o código encolhe. O tempo de entender o código, não.A pressão para aprovar rápido aumenta justamente quando há mais para ler.Confiança aparenteO código vem formatado, comentado e com bons nomes. O erro de segurança não tem cara de erro.O revisor relaxa onde deveria olhar com mais cuidado.AutonomiaO assistente não só sugere: executa comandos, lê arquivos, instala dependências e faz commits.O risco deixa de ser só o que a IA escreve e passa a ser o que ela faz.

A confiança aparente tem nome e tem estudo. Num experimento divulgado em 2022 e publicado no ACM CCS 2023, pesquisadores de Stanford observaram que os participantes com acesso a um assistente de IA escreveram código significativamente menos seguro do que os que não tinham, e ao mesmo tempo eram mais propensos a acreditar que o próprio código estava seguro. O perfil de IA generativa do NIST, de julho de 2024, chama de confabulação a produção de conteúdo errado apresentado com confiança, e trata como risco próprio desses sistemas a relação entre pessoa e IA que leva ao viés de automação e à dependência excessiva. É o retrato de um revisor diante de um pedido de alteração bem formatado no fim do dia.

A autonomia é a mudança menos discutida e a que mais pesa. A OWASP, na edição 2025 da sua lista de riscos de aplicações com modelos de linguagem, chama de agência excessiva (excessive agency) a vulnerabilidade de um sistema executar ações danosas a partir de uma saída inesperada, ambígua ou manipulada do modelo, e aponta três causas: funções demais, permissão demais e autonomia demais. Um assistente de código que roda com as permissões de quem programa tem as três por padrão. Ele lê o que essa pessoa lê, executa o que ela executa e alcança o que ela alcança.

O reflexo comum diante disso é pedir mais cuidado na revisão. Não escala, porque a revisão é justamente o recurso que a IA não multiplicou. O outro reflexo, proibir o uso, também falha: empurra a IA para contas pessoais, sem configuração da empresa e sem registro do que foi feito. O que funciona é tirar da revisão humana tudo o que uma máquina consegue barrar sozinha, para que a pessoa revise o que só uma pessoa consegue julgar.

## Quais são as três camadas da governança de IA no código?

Quem usa a IA, o que a IA alcança e por onde o código chega a produção. São três perguntas diferentes, com controles diferentes, e juntas cobrem o percurso inteiro, de quem digita até o servidor. Cada texto desta série mora numa delas.

CamadaPerguntaO que governaO que acontece se ela faltar1. Quem usa a IAO que o assistente pode fazer na máquina de quem trabalha?Configuração gerenciada, hooks, guardrail e trilhaO assistente executa, lê ou envia o que ninguém autorizou, e ninguém fica sabendo2. O que a IA alcançaQue dados e sistemas a IA pode ler, e o que ela nunca escreve?Acesso só de leitura, máscara de dado pessoal e destinos permitidosUm dado de produção alterado, ou um dado pessoal enviado a um terceiro3. Por onde o código chegaComo o que a IA escreveu vira produção, e quem impede o que não deve virar?Pull request, CI que bloqueia, validador de deploy, segredos e isolamentoCódigo que ninguém revisou rodando em produção, por um atalho

Uma regra atravessa as três camadas e se repete em todos os textos: controle é mecanismo, não boa vontade. Cada controle precisa responder a três perguntas. O que ele barra? Como se prova que ele barra? O que acontece quando ele falha? Um controle que não responde à segunda é uma esperança, e um que não responde à terceira é uma surpresa marcada para o pior dia.

Um exercício para amanhã: pegue a última mudança que foi a produção e, para cada camada, responda que controle teria barrado um erro nela e como você sabe que ele teria barrado. Onde a resposta for "alguém teria percebido", a camada ainda não existe.

### Camada 1: quem usa a IA

O assistente de código roda na máquina de quem programa, com as permissões dessa pessoa. A primeira camada decide o que ele pode fazer ali, e começa por uma troca: a regra deixa de ser texto que o modelo lê e passa a ser um programa da empresa que roda em pontos fixos do fluxo, antes e depois de cada ação. Sobre esse mecanismo vem um guardrail, que faz três perguntas a cada ação do assistente: quão arriscado é isto, fere alguma regra da casa, foi isto que a pessoa pediu? O modelo que classifica só estima probabilidades. Quem decide é a política da empresa, escrita em código, e uma pergunta sem resposta nunca vira "pode".

Por cima de tudo fica a configuração gerenciada, a camada que a empresa distribui de forma central e que o usuário não sobrescreve na própria máquina. Plugins obrigatórios, limites fixados e segredos que nunca passam pelo repositório entram sozinhos no próximo login de quem chega ao time. Sem ela, a governança vale até a primeira pessoa com pressa.

### Camada 2: o que a IA alcança

Ligar a IA aos dados reais da empresa é o que a torna útil, e também o que a torna perigosa. A segunda camada define o que ela lê e garante o que ela nunca escreve. "Só leitura" não é promessa da ferramenta nem frase na instrução. É garantia em três lugares independentes: a permissão do usuário no banco, a recusa do serviço em subir fora desse modo e o escopo do perfil de quem pergunta. Uma falha sozinha não basta para a IA escrever.

Na mesma camada ficam duas decisões que costumam ser esquecidas. O dado pessoal sai mascarado antes de chegar ao modelo, e não depois. E existe uma lista de destinos para onde a IA pode mandar dados; o que não está na lista não recebe nada. A LGPD chama a lógica por trás disso de necessidade: tratar só o mínimo indispensável para a finalidade. Quando a chave que liga a IA aos dados é retirada, as funções de IA caem, e isso é desenho, não falha.

### Camada 3: por onde o código chega

A terceira camada é o trilho propriamente dito. Todo código chega a produção por um caminho só, o pull request, e produção nunca compila nada: só roda o que já foi construído, testado e aprovado. Voltar atrás também é um pull request. Um validador recusa, ainda no pedido de alteração, o que a casa não aceita em produção, antes de alguém precisar lembrar.

Esse caminho é guardado por oito checks obrigatórios: lint, tipos, testes, segredos, análise estática, dependências, imagem e validador de deploy. Eles bloqueiam o merge, porque um check que só alerta ensina o time a ignorar o vermelho. Segredo não passa pelo terminal nem fica ao alcance do assistente. A máquina que executa o código de cada pedido de alteração, ainda não revisado, não alcança produção. E produção não tem nenhuma porta de entrada aberta.

O fecho atravessa as três camadas: provar que tudo isso funciona e saber desligar. Uma trilha que mostra quem fez o quê, um botão que desliga a IA para todos e uma rotina curta que impede o desenho de apodrecer.

## Por que regra escrita não basta?

Porque regra escrita é texto que o modelo pode ou não seguir. Uma política de uso de IA num documento, num arquivo de instruções do repositório, como o CLAUDE.md do Claude Code, ou nas instruções da organização entra no contexto do modelo como mais um trecho a considerar. Funciona quase sempre. E "quase sempre" é exatamente o problema quando o assunto é segredo, dado pessoal ou produção.

Os motivos são conhecidos. O modelo pondera a instrução contra tudo o mais que está no contexto: o pedido da pessoa, o código aberto, a saída do último comando. Numa conversa longa, a regra fica longe. E o contexto pode trazer texto de fora com instrução escondida, numa página, num comentário de pull request ou na resposta de um conector. A OWASP põe essa injeção de instrução (prompt injection) no topo da lista de 2025 e registra que técnicas como busca em base própria e ajuste fino não a eliminam. O que ela recomenda é tratar privilégio em código, fora do modelo, e exigir aprovação humana para o que é de alto risco.

A saída é transformar a regra em mecanismo. Nos assistentes de código, isso tem nome: hook, um ponto fixo do fluxo, antes de usar uma ferramenta, depois de usá-la ou ao abrir a sessão, em que um programa da empresa roda e decide, independentemente do que o modelo achou. A diferença cabe em três verbos. A instrução orienta. A skill ensina. O hook roda.

O erro mais caro não é ter só texto. É ter um texto que afirma proteção mecânica onde o mecanismo não roda. Uma skill viaja para superfícies onde o hook não existe, como o chat no navegador, e continua dizendo que a proteção está ativa. O time passa a se achar protegido sem estar, e isso é pior do que não ter regra nenhuma. Por isso todo mecanismo precisa avisar, ao abrir a sessão, se está pronto ou se não está operante.

Nem tudo precisa virar mecanismo. Poucas proibições absolutas bloqueiam: segredo escrito em código, escrita direta em banco de produção, dado apagado em definitivo. O resto orienta ou pede aprovação, para que o time não aprenda a contornar um bloqueio que dispara toda hora. O próximo texto desta série detalha essa fronteira.

Para amanhã, abra o arquivo de instruções do assistente do seu time e marque cada frase que é uma proibição. Para cada uma, pergunte o que acontece se o modelo não a seguir. Onde a resposta for "vaza um segredo" ou "altera produção", a regra precisa virar mecanismo.

## O que é o "caminho estreito" até produção?

É um caminho só para produção, igual para pessoa e máquina, que bloqueia em vez de alertar e prova, a cada uso, que está funcionando. As quatro propriedades dependem uma da outra. Tire qualquer uma e o caminho alarga.

Um só. Se existe um jeito de mudar produção sem passar pelo repositório, ele vai ser usado no dia em que a IA sugerir um atalho, e ela vai sugerir. Acesso direto ao servidor para "só ajustar um arquivo", build feito na própria máquina de produção, variável trocada à mão num painel: cada um desses é um segundo caminho, sem revisão e sem registro. O desenho fecha todos, inclusive o da emergência. Em incidente, voltar atrás é um pull request que troca a versão, e por isso o caminho precisa ser rápido o bastante para ninguém ter motivo de sair dele.

Igual para pessoa e máquina. O assistente não ganha um caminho especial, e o desenvolvedor mais experiente também não. A mesma CI, os mesmos checks, a mesma aprovação. A razão é prática: num pull request de hoje, as linhas da pessoa e as da IA estão misturadas, e ninguém consegue separá-las com segurança. A autoria deixou de ser informação útil para decidir o que entra. O que decide é o que o código faz.

Bloqueia, não alerta. Um controle que só avisa vira paisagem em poucos dias. O time aprende que vermelho não impede nada e passa a ignorar também o vermelho que importava. Os oito checks obrigatórios bloqueiam o merge e, por isso, precisam ser justos: bloquear só o que tem correção, avisar do resto e ter um dono para cada aviso.

Verificável. Cada controle do caminho tem uma prova que se repete, e não um "foi configurado". A máquina que roda os testes tenta alcançar a rede interna e precisa falhar. O validador recebe um serviço com porta exposta e precisa recusar. A varredura de segredos recebe um segredo de teste e precisa barrar. Se a prova parar de falhar quando deveria, o controle caiu, e alguém fica sabendo.

Nada disso é invenção desta série. O framework de desenvolvimento seguro do NIST, o SSDF, organiza o tema como práticas de processo: preparar a organização, proteger o software, produzir software bem protegido e responder a vulnerabilidades. Em julho de 2024, ele ganhou um complemento para IA generativa. O caminho estreito é a forma operacional dessa ideia para um time que escreve código com IA: quem carrega a segurança é o processo, não a promessa da ferramenta.

O erro comum é estreitar o caminho só para a IA. Bloquear o assistente e deixar a pessoa com acesso direto ao servidor não estreita nada. A IA sugere o comando, a pessoa cola no terminal, e o atalho continua aberto, agora com uma etapa a mais e nenhum registro.

## O que fica com as pessoas?

Três coisas que nenhum mecanismo faz: revisar o que entra, decidir o risco que se aceita e apertar o botão de desligar. O trilho existe para que as pessoas parem de fazer o que a máquina faz melhor, como procurar segredo esquecido ou dependência vulnerável, e se concentrem no que só elas fazem. No AI RMF do NIST, de janeiro de 2023, governar é a função transversal, a que define papéis, responsabilidades e cultura, e dá sentido a mapear, medir e gerenciar.

A revisão. Quem aprova um pull request responde pelo que entrou, tenha escrito ou não. Com os checks no lugar, a revisão muda de natureza. A pessoa não procura vírgula nem chave esquecida, porque isso já foi barrado. Ela pergunta se aquilo deveria existir, se faz o que diz e se mexe em algo que não devia, que é a pergunta que nenhum check responde. Por isso o desenho prevê mais de um dono de código para cada área: com um só, todo pedido desse dono trava, e a pressão para liberar sem revisão volta.

O risco aceito. Todo desenho real tem desvios: orçamento que não comporta uma máquina a mais, sistema antigo que não cabe no trilho, ferramenta que ainda não bloqueia. O desenho reduz o risco, não o elimina, e dizer isso em voz alta é parte do método. O desvio é decidido pela diretoria, escrito com nome, data e motivo, e revisto. O mesmo vale para os limites do guardrail: quem pode mudá-los é a diretoria, por um pedido de alteração, e não quem se incomodou com um bloqueio numa tarde.

O botão de desligar. Uma governança que não se desliga é refém da própria ferramenta. É preciso um comando único que desligue uma função de IA para todos de uma vez, com quem pode acioná-lo definido antes do incidente. E é preciso uma trilha que mostre o que foi tentado e o que foi executado, guardada fora da máquina onde aconteceu, com retenção de um ano, e honesta sobre o que ela não consegue mostrar.

Tudo isso só continua de pé com uma rotina curta: 5 minutos por dia, 30 minutos por semana, 2 horas por mês e meio dia por trimestre, cada uma com o que cabe nela. Entrega, numa implantação de governança, é a prova de cada controle, e não "subiu".

## Por onde começar numa empresa pequena?

Pela fundação, antes da automação. Primeiro o caminho único, depois os segredos, depois o assistente governado, e só então o que exige mais maquinário. A ordem importa mais do que a velocidade: um guardrail sofisticado na máquina de quem programa não protege nada se o servidor de produção aceita mudança feita à mão.

Imagine um time de cinco pessoas que adotou um assistente de código há alguns meses. Ninguém ali tem tempo para um projeto de governança, e ninguém precisa. A sequência abaixo cabe em ciclos curtos, e cada passo vale sozinho, mesmo que o seguinte demore.

1. Um caminho só. Todo código num repositório da empresa, branch principal protegido e merge só por pull request com aprovação de alguém além do autor. Confira que a proteção está ligada de fato, e não só combinada.
2. Segredos fora do código e do terminal. Um cofre de segredos, um segredo por uso, nada escrito em arquivo versionado e nada colado em linha de comando, com troca semestral registrada sem o valor.
3. Poucos checks que bloqueiam. Comece por segredos, testes e dependências com correção disponível, bloqueando o merge, e amplie até os oito quando o time confiar no vermelho.
4. Produção sem atalho. Deploy só pelo que o repositório diz, produção sem build e sem porta de entrada, e a máquina de testes separada da de produção.
5. O assistente governado. Configuração gerenciada pela empresa e as poucas proibições absolutas transformadas em mecanismo, com o aviso de "não operante" visível para quem usa.
6. Dados só de leitura. Quando a IA precisar de dados reais, leitura garantida no banco, dado pessoal mascarado antes do modelo e destinos permitidos em lista.
7. Prova e desligamento. Trilha fora da máquina, botão de desligar testado e a rotina na agenda de alguém com nome.

O erro comum de quem começa é inverter a ordem: instalar a ferramenta mais visível, um scanner ou um guardrail, sobre um caminho que ainda tem atalhos. A ferramenta acende alertas, ninguém tem tempo de tratá-los, e o time conclui que governança é ruído. Começar pela fundação faz o contrário. Cada passo fecha uma porta, e porta fechada não gera alerta.

Os textos seguintes desta série seguem esse percurso. Começam pela primeira camada: por que a política de uso de IA precisa virar mecanismo, como um guardrail decide entre risco, regra e pedido, e o que o time não consegue desligar. Passam pela segunda, com a IA que lê e não escreve dados de produção. Descem a terceira: o pull request como único caminho, o gate que bloqueia em vez de alertar, o segredo que não passa pelo terminal e a máquina que roda código de PR sem tocar produção. E terminam no que atravessa as três: provar que funciona e saber desligar.

## Perguntas frequentes

Preciso proibir o uso de IA no desenvolvimento para ter governança?

Não, e proibir costuma piorar. O uso vai para contas pessoais, sem configuração da empresa e sem registro do que foi feito. A governança permite o uso e estreita o caminho até produção: o assistente trabalha com as regras da empresa na máquina de quem programa, alcança só o que precisa ler, e todo código que ele ajuda a escrever passa pelo mesmo pull request, pelos mesmos checks e pela mesma aprovação humana.

Qual é a primeira coisa a fazer numa empresa pequena?

Fechar os atalhos até produção. Todo código num repositório da empresa, branch principal protegido e merge só por pull request aprovado por alguém além do autor. Sem isso, nenhum outro controle segura, porque sempre existe um jeito de mudar o servidor à mão. Em seguida vêm os segredos fora do código e do terminal, e só depois os controles na máquina de quem usa a IA.

Uma política de uso de IA escrita não resolve?

Orienta, mas não garante. Texto em documento, em arquivo de instruções ou nas configurações da organização é algo que o modelo pode ou não seguir, e conteúdo de fora pode trazer instruções contrárias. Funciona quase sempre, e "quase sempre" não basta para segredo, dado pessoal e produção. As poucas proibições absolutas precisam virar mecanismo: um programa da empresa que roda antes e depois de cada ação do assistente.

Trocar para um modelo melhor não reduz o risco?

Reduz pouco, e não de forma previsível. Num teste publicado pela Veracode em julho de 2025, com mais de 100 modelos, os maiores não se saíram significativamente melhor em segurança que os menores. O que reduz o risco de forma previsível é o caminho: checks que bloqueiam, segredos fora do alcance, produção sem atalhos e uma pessoa aprovando cada mudança. Com o caminho no lugar, o modelo vira peça trocável.

A IA pode revisar ou aprovar pull requests?

Pode ajudar a revisar, como mais um check que aponta problemas. Não aprova. A aprovação é de uma pessoa que responde pelo que entrou, tenha escrito ou não. Uma revisão automática por IA está sujeita aos mesmos erros confiantes do código que ela revisa, e por isso entra como apoio ao revisor humano, não como substituto dele.

O que significa "igual para pessoa e máquina"?

Que o código escrito pelo assistente de IA e o escrito por uma pessoa passam pelo mesmo caminho: o mesmo pull request, a mesma CI, os mesmos checks obrigatórios e a mesma aprovação. Nenhum dos dois tem atalho, nem o desenvolvedor mais experiente. Num pull request de hoje, as linhas da pessoa e as da IA estão misturadas, e a autoria deixou de ser informação útil para decidir o que entra.

## Fontes

1. [AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks, Veracode Research Reveals](https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/) · Veracode · 30 de julho de 2025
2. [Do Users Write More Insecure Code with AI Assistants?](https://arxiv.org/abs/2211.03622) · arXiv (versão publicada no ACM CCS 2023) · 7 de novembro de 2022
3. [Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence) · NIST · 26 de julho de 2024
4. [Artificial Intelligence Risk Management Framework (AI RMF 1.0)](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10) · NIST · 26 de janeiro de 2023
5. [OWASP Top 10 for LLM Applications 2025](https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/) · OWASP GenAI Security Project · 17 de novembro de 2024
6. [Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile (NIST SP 800-218A)](https://csrc.nist.gov/pubs/sp/800/218/a/final) · NIST Computer Security Resource Center · 26 de julho de 2024

### Uma conversa já separa o urgente do que pode esperar.

Entender como a sua operação está hoje é por onde começamos, não onde paramos.

[Conversar no WhatsApp](https://wa.me/5532998024931?text=Ol%C3%A1%2C%20vim%20pelo%20site%20e%20gostaria%20de%20conversar) [Como trabalhamos](https://franklinfreitas.com/como-trabalhamos#entender)

Série · parte 1 de 10

[IA no código: o caminho estreito até produção](https://franklinfreitas.com/blog/governanca-de-ia/#serie)

[Próximo Regra escrita não é regra: por que a política de IA virou mecanismo](https://franklinfreitas.com/blog/regra-escrita-nao-e-regra-politica-de-ia)

Por [Victor Freitas](https://franklinfreitas.com/sobre/victor-freitas) · Consultor em governança de tecnologia e IA · Franklin Freitas Consultoria

Conduz diagnósticos e implantações de governança de tecnologia e IA em pequenas e médias empresas, com experiência acumulada em provedores de internet. Mais de 20 anos no mercado de TI, com passagens por desenvolvimento, DevOps, infraestrutura, arquitetura de solução e AIOps. Casado, pai de duas filhas.

Franklin Freitas Consultoria é a marca de F. F. SOFTWARE HOUSE LTDA · CNPJ 67.982.774/0001-36 · Espera Feliz/MG

[victor@franklinfreitas.com](mailto:victor@franklinfreitas.com?subject=Contato%20pelo%20site) · [WhatsApp +55 (32) 99802-4931](https://wa.me/5532998024931?text=Ol%C3%A1%2C%20vim%20pelo%20site%20e%20gostaria%20de%20conversar)

[Como trabalhamos](https://franklinfreitas.com/como-trabalhamos) · [Produtos](https://franklinfreitas.com/produtos) · [Blog](https://franklinfreitas.com/blog/) · [Quem conduz](https://franklinfreitas.com/sobre/victor-freitas) · [Aviso de privacidade](https://franklinfreitas.com/privacidade) · Sem cookies e sem formulário.

© 2026 F. F. SOFTWARE HOUSE LTDA