TI e IA: como acabar com o conflito entre as duas equipes

As equipes de TI e IA costumam dividir o mesmo orçamento e o mesmo diretor, sob o rótulo de tecnologia, e trabalhar com prioridades opostas. A TI responde por controle, padronização e redução de risco. A equipe de IA responde por experimentação, flexibilidade e aprendizado rápido. Sem uma regra que concilie as duas, uma atrasa o trabalho da outra, e a organização paga pelos dois lados: projetos de IA que não chegam à operação e controles contornados por ferramentas paralelas.

Graham Kenny, Kim Oosthuizen e Ganna Pogrebna, que assessoram empresas nessa transição, descrevem três desacordos recorrentes: o que conta como dado, quem tem competência para decidir e se os sistemas existentes aguentam o que a IA quer construir sobre eles.

Por que as equipes de TI e de IA entram em conflito?

Cada equipe foi montada para um risco diferente. A TI passou décadas mantendo sistemas críticos no ar, e os processos dela existem para evitar a falha: mudanças aprovadas, ambientes separados, trilha de auditoria. A equipe de IA nasce para descobrir o que funciona, e mede o próprio trabalho pelo número de hipóteses testadas e pela velocidade com que um modelo chega ao uso. As duas lógicas têm razão de ser, e cada equipe enxerga a outra pelo defeito: a TI vê na IA um risco sem controle, e a IA vê na TI um obstáculo.

O desacordo custa mais quando ninguém tem autoridade para resolvê-lo. Em um banco com 36 mil empregados, as duas funções respondiam ao mesmo gerente-geral, um arranjo que parecia eficiente e deixava cada disputa sem decisão até o fim do projeto. Formaram-se duas culturas, com ferramentas duplicadas, regras inconsistentes e mais exposição a risco. A inovação ficava em projetos isolados, que não ganhavam escala, e o controle pesava sobre todos eles.

O que conta como dado

Para a TI, dado é o que cabe em tabelas e colunas, com dono, dicionário e regra de acesso. A IA generativa e os agentes de IA trabalham sobre outra matéria: transcrições de atendimento, contratos, e-mails, notas de serviço e registros de fluxo de trabalho. Em um conglomerado que atua em serviços financeiros, logística, imóveis e varejo, a chefia de IA resumiu a divergência dizendo que a TI não reconhecia como dado o material qualitativo e conversacional que os modelos usavam. As unidades mais próximas do cliente passaram a operar com uma definição, e a TI com outra.

A empresa resolveu a questão no nível da direção. Ampliou formalmente o inventário de dados da organização para incluir as fontes não estruturadas, classificadas como ativos estratégicos com o mesmo peso dos bancos de dados, e estendeu a elas as normas de dados que já existiam. A TI ganhou os controles de que precisava sobre esse material, e a equipe de IA passou a trabalhar com dados reconhecidos. A empresa também exigiu que cada aplicação de IA entrasse no fluxo de trabalho existente, como a fila de atendimento ou a análise de sinistros, em vez de funcionar como um sistema à parte.

A qualidade desse material é um trabalho próprio, que o artigo sobre dados não estruturados e IA generativa detalha.

O que fazer: inclua no inventário de dados as fontes não estruturadas que os projetos de IA já usam, cada uma com um responsável, a classificação de sensibilidade e o prazo de retenção, sob as mesmas normas que valem para os bancos de dados.

De competência para responsabilidade: quem responde por quê

No banco, a discussão começou como uma disputa sobre competência. Na TI, a gerência sênior argumentava que a equipe de IA não dominava os fundamentos e entregava sistemas sem painéis, sem governança e sem auditoria. A chefia de IA respondia que a TI tratava cada iniciativa como um risco de conformidade antes de entender o propósito dela, e que a equipe de IA pedia para entrar na governança mais cedo, para desenhar a auditabilidade desde o primeiro dia.

O banco começou pela estrutura. Separou a chefia de IA da chefia de TI, que antes respondiam ao mesmo gerente-geral. A TI ficou com a infraestrutura, a segurança cibernética, a resiliência e os controles de conformidade. A IA ficou com o desenvolvimento dos modelos, a experimentação e a implantação dos produtos de IA, sempre dentro do ambiente regulatório e de segurança do banco.

Em seguida, criou uma taxonomia obrigatória, apoiada na distinção que Thomas Davenport e Peter High descreveram na HBR em dezembro de 2024. De um lado fica a IA analítica: aprendizado de máquina, modelos preditivos e sistemas de decisão, cujos resultados precisam ser explicáveis e auditáveis. Do outro, a IA generativa, que produz textos, resumos e respostas em conversa, com outro perfil de risco. Cada formulário de entrada de projeto, modelo de análise de risco e relatório passou a indicar o ramo. A IA analítica ficou nos domínios auditáveis, como fraude, crédito e preço, e a generativa, em tarefas de menor risco, como redação e resumo, com controles adicionais para os usos de risco maior. A resistência da TI diminuiu quando ela viu que boa parte da IA já estava perto do mundo de governança que ela conhecia.

Por último, o banco reescreveu as descrições de cargo. Engenheiros de dados, cientistas de dados, engenheiros de aprendizado de máquina, donos de produto de IA e a TI tinham atribuições sobrepostas, e várias equipes achavam que eram donas do desenvolvimento, da implantação ou da validação dos modelos. Com os papéis redefinidos, os pontos de passagem entre eles ficaram visíveis. Quem busca uma referência externa para essa divisão tem a ISO/IEC 42001, publicada em dezembro de 2023, que especifica os requisitos de um sistema de gestão de IA, estabelecido, mantido e melhorado como os outros sistemas de gestão da organização.

O que fazer: escreva a taxonomia de IA da organização, com o ramo e o nível de controle de cada uso, e uma matriz de papéis que diga, para cada etapa do ciclo de um modelo, quem desenvolve, quem valida, quem implanta e quem aprova a passagem de uma etapa para a outra.

As três classes de caso de uso, pela fundação que exigem

Uma operadora de telecomunicações com 9.200 empregados chegou à IA no meio de uma consolidação. A TI acumulava décadas de sistemas em camadas, integrações ponto a ponto e infraestrutura em fim de vida, e funções críticas ainda trocavam dados por arquivos planos entre plataformas que não foram feitas para conversar. A equipe de IA treinou um modelo de linguagem próprio com os arquivos internos e passou a testá-lo em várias frentes, da redação de documentos à previsão de falhas na rede e de cancelamentos.

Os primeiros casos, de baixo risco e sem contato com a operação, funcionaram. Os seguintes dependiam de dados em tempo real, e os modelos que iam bem no ambiente de teste pioravam ou falhavam em produção, porque os dados chegavam fragmentados, inconsistentes ou atrasados. A equipe de IA atribuía a falha à lentidão da TI, e a TI, à pressa da IA em construir sobre uma base instável.

A operadora dividiu o portfólio em três classes. A primeira reúne os casos de pouca exigência de fundação, como redação de documentos, busca em arquivos de normas internas e ferramentas de conhecimento, que geram valor sobre um conjunto controlado de documentos, com regras de uso e revisão humana. A segunda, os casos que dependem de dados mais limpos sem intervir na operação, como a análise do sentimento dos clientes, cujos resultados são tratados como sinais para decisão humana. A terceira, os casos críticos, como a previsão de falhas na rede, a ação contra cancelamentos e a resposta automática ao cliente, que exigem fluxos de dados estáveis, identificadores consistentes e monitoramento em tempo real.

A empresa ligou o plano de IA ao plano de consolidação da TI em um único mapa de dependências, que mostra quais ambições de IA dependem de sistemas ainda instáveis. A pergunta mudou de "a TI está bloqueando a inovação?" para quais casos podem seguir agora, quais esperam uma melhoria da fundação e quais devem parar. Projetos que soavam modernos e não resolviam um problema definido pararam.

O que fazer: classifique cada caso de uso do portfólio em uma das três classes e ligue os da terceira aos marcos do plano de modernização da TI, em um mapa de dependências único; o caso que depende de um sistema instável espera o marco, que tem data e responsável.

Os mesmos indicadores para as duas equipes

O conglomerado e a operadora mudaram também a forma de medir. O conglomerado criou um modelo de responsabilidade conjunta, com estruturas de governança compartilhadas e indicadores ligados a resultados do cliente e do negócio. A TI continua dona da governança, da qualidade e da conformidade, e a IA, da experimentação e da entrega nos fluxos de trabalho, e as duas são avaliadas pelos mesmos resultados comerciais. Com a meta em comum, as duas equipes passaram a ter motivo para avançar juntas.

A operadora trocou os indicadores de atividade, como protótipos lançados e pilotos em andamento, por medidas de resultado e de prontidão. A consolidação da TI, um trabalho caro e pouco visível para o resto da empresa, passou a aparecer em termos de negócio, e o programa de IA ganhou credibilidade. Os resultados escolhidos foram concretos: a detecção mais cedo de falhas na rede, menos reclamações escaladas e alertas melhores de cancelamento. A ligação entre cada projeto de IA e uma linha do resultado financeiro é o tema do artigo sobre o ROI da IA.

O que fazer: tire do painel de tecnologia a contagem de pilotos e protótipos e ponha no lugar dois tipos de medida, o resultado de negócio de cada caso de uso e a prontidão da fundação que ele exige, com as metas das duas equipes sobre os mesmos números.

Conclusão

Nos três casos, o conflito entre TI e IA terminou com decisões tomadas acima das duas equipes. O conglomerado ampliou a definição de dado e aplicou a ela as normas da TI. O banco separou as chefias, classificou a IA pelo risco e reescreveu os papéis com os pontos de passagem à vista. A operadora ordenou os casos de uso pela fundação que cada um exige e ligou o plano de IA ao de modernização. O conglomerado e a operadora passaram a medir as duas equipes pelos resultados do negócio. O primeiro passo é o inventário: dos dados que a IA usa, dos papéis que se sobrepõem e dos casos de uso, com a classe de cada um.

Essas decisões assentam sobre a governança de serviços que a TI já pratica, e convém medir de onde a organização parte antes de redesenhá-la. A Jornada de Maturidade ITIL® da Takter faz uma avaliação objetiva das capacidades de gerenciamento de serviços e da maturidade do sistema de valor de serviço (SVS), incluídas a governança, as práticas e a melhoria contínua, e liga a governança aos indicadores de negócio.

Fontes

• Graham Kenny, Kim Oosthuizen e Ganna Pogrebna, AI and IT Teams Often Clash. But They Don't Have To., Harvard Business Review, julho de 2026.
• Thomas H. Davenport e Peter High, How Gen AI and Analytical AI Differ, and When to Use Each, Harvard Business Review, dezembro de 2024.
• ISO e IEC, ISO/IEC 42001:2023, Artificial intelligence: Management system, dezembro de 2023.