Perspetiva
A IA pode resumir um documento em segundos. Pode classificar pedidos, extrair informação, preparar respostas, analisar grandes conjuntos de dados, identificar padrões e, cada vez mais, executar ações em sistemas empresariais.
Essa rapidez é extraordinária.
Mas rapidez não é o mesmo que melhoria.
Dê à IA um processo bem desenhado, com informação fiável, regras claras e supervisão adequada, e ela pode eliminar grandes quantidades de trabalho repetitivo.
Dê-lhe dados fragmentados, responsabilidades pouco claras, sistemas duplicados e um fluxo de trabalho inconsistente, e a IA não resolve necessariamente a desorganização.
Pode acelerá-la.
Por isso, a pergunta mais importante numa iniciativa de IA não é «Onde podemos usar IA?», mas «Que problema de negócio queremos resolver e está a operação preparada para a participação da IA?»
Cada implementação de IA funciona dentro de um sistema mais amplo.
Depende de informação. Interage com processos. Pode obter documentos, interpretar registos, recomendar ações, iniciar fluxos de trabalho ou comunicar com clientes e colaboradores.
Isto significa que a qualidade da experiência de IA é influenciada pela qualidade do ambiente à sua volta.
A IBM descreve dados preparados para IA como dados acessíveis, governados, seguros e apoiados. Identifica também a fragmentação, a má qualidade dos dados e os riscos de governação como obstáculos comuns à preparação para IA.[1]
Considere uma empresa com informação de clientes dispersa entre um CRM, folhas de cálculo, caixas de email e unidades partilhadas.
Agora dê a um assistente de IA a tarefa de responder a «O que se passa com este cliente?»
Em que sistema deve confiar? Que registo está atualizado? Quem gere a conta? A que documentos pode aceder a IA? Que informação é confidencial? Se dois sistemas discordam, qual prevalece?
A IA não criou esses problemas.
Tornou-os visíveis.
A IA não elimina a desorganização operacional. Pode fazê-la avançar mais depressa.
Durante anos, as organizações conseguiram tolerar dados imperfeitos porque os colaboradores aprenderam a compensá-los.
Sabiam que uma folha de cálculo estava mais atualizada do que outra. Sabiam quais os nomes de clientes introduzidos incorretamente. Sabiam que determinado campo não era mantido. Sabiam a quem perguntar quando a informação não fazia sentido.
A IA não possui automaticamente esse conhecimento institucional. Trabalha com a informação e o contexto disponíveis.
A IBM define a qualidade dos dados para IA através de características como exatidão, integridade, fiabilidade e adequação ao uso, observando que dados incorretos, incompletos ou enviesados podem produzir resultados de IA pouco fiáveis.[1]
Isto muda a importância da qualidade dos dados.
Um registo de cliente duplicado já não é apenas um incómodo administrativo. Um procedimento desatualizado não é apenas um documento antigo no SharePoint. Um registo mal classificado não é apenas algo que um colaborador sabe ignorar.
Quando a IA começa a obter, analisar ou agir sobre essa informação, essas inconsistências podem tornar-se dados de entrada para decisões e ações automatizadas.
Dados limpos, por si só, não criam uma boa implementação de IA.
O processo à sua volta também precisa de fazer sentido.
Imagine uma organização que recebe pedidos de serviço por vários canais: email, telefone, formulário web, mensagens diretas aos colaboradores e uma folha de cálculo mantida por outro departamento.
A gestão quer que a IA classifique os pedidos e os encaminhe automaticamente.
Tecnicamente, isso pode ser possível.
Mas, operacionalmente, há perguntas que vêm primeiro. O que constitui um pedido válido? Que informação é necessária? Como se determina a urgência? Quem é responsável por cada tipo de pedido? O que acontece quando falta informação? Que casos exigem aprovação? Que casos nunca devem ser tratados automaticamente? Como se regista a conclusão?
Se estas regras existem apenas na cabeça dos colaboradores, a organização ainda não tem um problema de IA.
Tem um problema de definição de processos.
A conversa sobre IA centra-se muitas vezes no que um sistema consegue fazer.
As organizações também precisam de decidir o que ele deve fazer.
Deve a IA preparar a resposta ao cliente? Deve enviá-la? Deve recomendar um preço? Deve aprová-lo? Deve resumir um registo médico? Deve tomar uma decisão clínica? Deve identificar uma transação financeira invulgar? Deve agir sobre essa transação?
São níveis de responsabilidade muito diferentes.
O quadro de gestão de riscos de IA do NIST trata a IA como um desafio sociotécnico de gestão de riscos, em vez de apenas uma implementação tecnológica. Organiza essa gestão em quatro funções — Governar, Mapear, Medir e Gerir — e destaca características como fiabilidade, segurança, responsabilidade, transparência, explicabilidade e privacidade.[2]
Isto é particularmente importante quando as organizações passam de IA que gera informação para IA que pode iniciar ações.
Quanto maior for a consequência de uma ação, mais deliberadamente é necessário definir permissões, supervisão, encaminhamento de casos e responsabilidade.
A IA não precisa de substituir um fluxo de trabalho para o melhorar.
Muitas vezes, o melhor desenho é a IA tratar de uma parte do trabalho.
Um sistema de IA pode extrair informação de um documento recebido, classificar o pedido, localizar registos relevantes, resumir o histórico e preparar uma recomendação.
Depois uma pessoa toma a decisão.
Esta divisão é importante.
O objetivo não é apenas: pessoa OU IA. É: que trabalho beneficia da rapidez da máquina e que trabalho exige discernimento humano?
O processamento rotineiro de informação pode ser um excelente candidato à IA. Situações ambíguas, decisões sensíveis, exceções e ações com consequências importantes podem exigir análise humana.
Esses limites devem ser desenhados intencionalmente, em vez de descobertos depois de algo correr mal.
Outro erro comum é começar por um produto.
Uma organização compra uma plataforma de IA e depois pergunta «Para que a podemos usar?»
Isto inverte o problema.
Comece pela operação.
Onde se perde tempo? Onde procuram os colaboradores repetidamente informação? Onde se reintroduzem dados? Onde esperam os clientes? Onde leem os colaboradores centenas de documentos para encontrar alguns detalhes importantes? Onde se atrasam as decisões por falta da informação certa?
Estes problemas podem revelar excelentes oportunidades de IA.
Outros podem revelar algo muito mais simples: uma mudança de processo, uma integração de sistemas, um formulário melhor, uma limpeza da base de dados, uma automação de fluxo de trabalho ou uma política mais clara.
Nem todos os problemas operacionais exigem inteligência artificial.
Por vezes, a decisão mais inteligente sobre IA é não a utilizar.
A IA deve entrar num sistema desenhado — não tornar-se o sistema.
Quando a IA participa em fluxos de trabalho operacionais, a governação não pode ser apenas um documento de política guardado noutro local.
Tem de integrar o funcionamento do sistema.
Quem pode aceder à IA? A que informação pode aceder? Que ações pode executar? O que fica registado? Quando é necessária aprovação humana? O que acontece quando o sistema tem dúvidas? Como se avaliam os resultados? Quem responde quando algo corre mal?
O NIST recomenda especificamente considerar a confiança na IA durante a preparação, o desenho e desenvolvimento, a implementação, a utilização, os testes e a avaliação — não apenas depois de o sistema estar lançado.[2]
Isto torna a governação uma questão de desenho operacional.
Não algo pensado depois.
Uma implementação de IA pode parecer impressionante sem alcançar muito.
O número de instruções não é um resultado de negócio. O número de resumos gerados por IA não é um resultado de negócio. O número de colaboradores com licenças de IA não é um resultado de negócio.
As perguntas úteis são operacionais. O tempo de processamento diminuiu? Os colaboradores perderam menos tempo a procurar informação? Os tempos de resposta melhoraram? O retrabalho diminuiu? Os clientes receberam respostas mais depressa? Os colaboradores ganharam capacidade para tarefas de maior valor? A qualidade das decisões melhorou? A organização reduziu o risco operacional?
A tecnologia importa.
Mas, em última análise, a IA deve ser avaliada pelo que mudou na operação.
A conversa sobre preparação para IA torna-se frequentemente uma conversa tecnológica.
Que modelo? Que plataforma? Que fornecedor? Que integração?
Estas perguntas serão importantes mais tarde.
Mas há outras mais fundamentais. O processo está compreendido? Os dados são suficientemente fiáveis para o uso previsto? As responsabilidades são claras? Os sistemas estão adequadamente ligados? As permissões estão definidas? Os pontos de revisão humana estão identificados? Há um resultado de negócio mensurável?
Se estas bases faltam, acrescentar mais inteligência não torna necessariamente a organização mais inteligente.
Pode apenas fazer um sistema instável avançar mais depressa.
Na DaVinci-X, é por isso que abordamos a IA como parte da modernização operacional, e não como uma compra tecnológica isolada. O trabalho começa pela compreensão da operação — processos, informação, sistemas e pessoas — antes de decidir onde pertence a IA.
Porque a IA deve ampliar uma boa operação.
Não compensar uma que não funciona.
Estrutura antes de inteligência.
