O seu produto deve usar IA? Um guia prático

A IA pode ser útil num produto, mas «acrescentar IA» não é um requisito de produto. Comece pelo problema do utilizador, pela decisão que o software tem de sustentar e pelo custo de errar essa decisão.

A pressão para adotar é real, e a lacuna por trás dela também.

O 2026 AI Index (abre num novo separador) da Stanford HAI relata que a adoção de IA nas organizações subiu para 88 % das organizações inquiridas em 2025. Nota também que o uso de agentes de IA «continua no início» em quase todas as funções de negócio.

O estudo 2026 State of AI in the Enterprise (abre num novo separador) da Deloitte inquiriu 3.235 quadros superiores em 24 países. Concluiu que 74 % das organizações esperam aumentar receitas com IA, contra 20 % que já o fazem.

A adoção é quase universal. O valor concretizado não é.

Essa lacuna é a razão para abrandar o tempo de uma conversa antes de assumir compromissos. A questão não é se a IA é capaz. É se esta funcionalidade, para este utilizador, corresponde a um problema com a forma que a IA resolve bem.

Quando a IA encaixa e quando não encaixa

Um fluxo de trabalho normal é muitas vezes a melhor escolha quando as regras são claras. Formulários, permissões, pesquisa, cálculos, notificações e tarefas agendadas não precisam de um modelo de linguagem só porque existe um.

Não é uma posição na contramão. As Rules of Machine Learning (abre num novo separador), a orientação interna da Google para engenheiros de ML, abrem com uma instrução direta: «Não tenha medo de lançar um produto sem aprendizagem automática».

O raciocínio é que uma regra simples já capta boa parte do valor. A aprendizagem automática ganha o seu lugar quando essas regras ficam demasiado emaranhadas para manter.

Um fluxo de trabalho convencional costuma ser a melhor resposta quando:

• as regras podem ser escritas e acordadas por quem é responsável pelo processo
• a mesma entrada deve produzir sempre a mesma saída
• o custo de uma resposta errada é alto e a correta pode ser conhecida à partida
• alguém precisa de explicar com precisão porque é que o sistema fez o que fez
• os dados já estão estruturados, validados e completos

A IA ganha o seu lugar quando a entrada é desarrumada, imprevisível ou difícil de delimitar com regras fixas:

• resumir documentos longos, tópicos de conversa ou notas de chamadas
• classificar mensagens em texto livre cuja formulação varia muito
• extrair campos de documentos que nunca seguem um único modelo
• ajudar uma pessoa a explorar informação em vez de decidir por ela
• redigir uma primeira versão que um humano vai rever e editar

O padrão da segunda lista é que uma pessoa continua no circuito. A saída é um rascunho, uma sugestão ou um ponto de partida, e não uma decisão final.

É normalmente aí que estas funcionalidades ganham primeiro o seu lugar.

Comece pela pergunta certa

A primeira pergunta não é «que modelo vamos usar?». Pergunte antes: «o que deve o utilizador conseguir fazer, e onde entra a incerteza no fluxo de trabalho?». Essa resposta determina se a IA pertence ao produto.

Decida como é um bom resultado antes de construir. Um resumo em rascunho pode bastar com uma verificação humana rápida. Uma decisão que o software toma sozinho pode exigir controlos mais apertados, uma explicação clara e uma forma segura de a parar ou corrigir.

O AI Risk Management Framework (abre num novo separador), publicado em janeiro de 2023 como orientação voluntária do NIST, di-lo com clareza. Entre as suas características dos sistemas fiáveis, ser válido e fiável é «uma condição necessária da fiabilidade».

É a base sobre a qual assentam as outras características. Uma funcionalidade impressionante mas pouco fiável não passou a primeira fasquia.

Perguntas a fazer antes de se comprometer

Se alguém propõe uma funcionalidade com IA, uma lista curta de perguntas costuma separar um plano ponderado de um entusiasmado:

1. Que tarefa é que isto faz, e como a faríamos sem IA?
2. Quanto custa ao utilizador uma resposta errada, e quem dá por ela primeiro?
3. Que dados é que a funcionalidade vê, e para onde vão?
4. Como a vamos testar antes do lançamento, e com que frequência depois?
5. O que faz o produto quando o modelo está indisponível ou incerto?
6. Quanto custa isto por utilizador por mês a dez vezes o volume atual?

Nenhuma delas exige formação técnica para ser feita. Todas são difíceis de responder de forma convincente sem ela.

Desenhe para a revisão humana

A revisão humana não é uma fórmula vaga de segurança. Dê a quem revê contexto suficiente para verificar a saída, uma forma clara de a editar e um caminho para reportar uma falha que a equipa de produto possa investigar.

Os referenciais estabelecidos pedem uma supervisão que possa mostrar por escrito, não uma que tenciona fazer.

A função Map do referencial do NIST espera que «os processos de supervisão humana sejam definidos, avaliados e documentados de acordo com as políticas da organização».

Na UE, Article 14 of the AI Act (abre num novo separador) exige que os sistemas da sua categoria de alto risco sejam concebidos de modo «a poderem ser efetivamente supervisionados por pessoas singulares durante o período em que estão em utilização».

Nem todos os produtos caem nessa categoria. O princípio de conceção continua a ser um padrão razoável muito antes de se tornar uma obrigação legal.

A orientação de segurança concorda. O OWASP Top 10 for LLM Applications (abre num novo separador) lista Excessive Agency entre os seus riscos de 2025.

A mitigação recomendada é direta: «utilize controlo com intervenção humana para exigir que uma pessoa aprove ações de alto impacto antes de serem executadas».

Se uma funcionalidade pode gastar dinheiro, enviar mensagens ou alterar registos por conta própria, esse passo de aprovação faz parte da construção. Não é uma tarefa de reforço posterior.

Fixe as regras de dados antes de construir

Acesso a dados e privacidade têm de fazer parte da conceção. Identifique que informação a funcionalidade recebe, onde é processada, quanto tempo é conservada e que pessoas ou sistemas podem aceder ao resultado.

A OWASP coloca Sensitive Information Disclosure (abre num novo separador) em segundo lugar entre os seus riscos de LLM de 2025. A sua orientação reduz-se a uma regra que a maioria das equipas conhece e salta sob pressão de prazos: «limite o acesso a dados sensíveis com base no princípio do menor privilégio».

O modelo é mais um sistema com acesso à informação dos seus utilizadores, e deve ser delimitado como tal.

Os fornecedores publicam condições concretas, e diferem o suficiente para importarem. Três merecem leitura antes de a conceção ficar fixada:

• Utilização para treino. A documentação da OpenAI sobre controlos de dados (abre num novo separador) afirma que «os dados enviados para a API da OpenAI não são usados para treinar ou melhorar modelos da OpenAI», com uma janela de conservação separada para monitorização de abusos.
• Conservação. A documentação da Anthropic sobre conservação de dados (abre num novo separador) descreve a conservação zero como os prompts e as respostas não ficarem armazenados em repouso depois de a resposta ser devolvida. A sua própria tabela de elegibilidade marca as funcionalidades com estado como exceções, pelo que a conservação zero não é geral.
• Onde corre a inferência. A geografia é configurável e tarifada à parte. A documentação da Anthropic sobre residência de dados (abre num novo separador) nota que a inferência apenas nos EUA «é tarifada a 1,1 vezes a tarifa padrão».

Se o produto trata dados pessoais de pessoas na UE, a obrigação na fase de conceção é explícita.

As orientações da Comissão Europeia sobre proteção de dados desde a conceção e por defeito (abre num novo separador) afirmam que as organizações «devem assegurar que os dados pessoais são tratados com o mais elevado nível de proteção da privacidade» por defeito.

Essa é uma decisão tomada antes da integração, não depois do incidente.

Planeie o custo por utilizador

Não assuma que um serviço de IA alojado é gratuito porque a primeira experiência sai barata. Utilização, armazenamento, monitorização, repetições, tempo de revisão e futuras mudanças de modelo afetam todos o custo de operação.

Os fornecedores de IA costumam cobrar pela quantidade de texto processada, pelo que o custo cresce com o uso e não com o número de pessoas.

As alavancas estão nomeadas na própria documentação de preços dos fornecedores (abre num novo separador): escolha do modelo, cache de prompts, custo adicional de tokens nas chamadas a ferramentas e processamento em lote. A API Batch da Anthropic oferece «um desconto de 50 % tanto nos tokens de entrada como de saída» para trabalho assíncrono.

Uma funcionalidade que não é viável a preço cheio pode ser aceitável quando o trabalho não precisa de ser imediato.

Há também uma dimensão de segurança. A entrada Unbounded Consumption (abre num novo separador) da OWASP descreve como «ao iniciar um volume elevado de operações, os atacantes exploram o modelo de custo por utilização dos serviços de IA na nuvem».

A isto chama-se por vezes negação de carteira. Limites de taxa, quotas e monitorização de utilização pertencem à primeira versão, não à segunda.

Teste primeiro com exemplos reais

Construa um pequeno conjunto de testes antes de dar a funcionalidade por pronta. Use exemplos representativos, inclua casos difíceis e registe os tipos de erro que importam a quem vai usar o produto.

Ambos os grandes fornecedores tratam isto como algo que se faz primeiro, não algo que se acrescenta depois.

As orientações da Anthropic sobre o desenvolvimento de avaliações empíricas (abre num novo separador) são específicas quanto à forma de um conjunto útil: «seja específico da tarefa: desenhe avaliações que espelhem a distribuição real das suas tarefas. Não se esqueça de contar com os casos limite!».

A documentação da OpenAI sobre avaliações (abre num novo separador) enquadra a mesma prática como perceber o desempenho de uma aplicação face às expectativas. É isso que torna seguro lançar uma alteração de modelo ou de prompt.

Uma avaliação útil não precisa de prever cada resposta. Deve mostrar se a funcionalidade é útil para a sua tarefa, onde falha e quando o fluxo de trabalho tem de devolver o controlo a uma pessoa.

A avaliação também não para no lançamento. As orientações da Microsoft sobre observabilidade (abre num novo separador) descrevem um ciclo de vida que continua em produção com «avaliação de qualidade e segurança do tráfego de produção a uma taxa de amostragem».

A utilização real vai conter entradas que o seu conjunto de testes nunca imaginou.

Planeie a alternativa

A alternativa também precisa de um desenho prático. Se o modelo estiver indisponível, demasiado lento ou incerto, o produto deve mesmo assim explicar o que o utilizador pode fazer a seguir, em vez de deixar um estado vazio ou uma resposta enganadora.

Decida antecipadamente o que a funcionalidade faz em três situações: quando o modelo não devolve nada aproveitável, quando o pedido excede o tempo e quando a confiança é baixa.

Cada uma é uma decisão de produto com consequências visíveis para o utilizador. Cada uma é mais barata agora do que durante um incidente.

Vale também a pena decidir com que facilidade poderia mudar de modelo ou de fornecedor mais tarde. Guardar prompts, conjuntos de avaliação e uma interface fina entre produto e modelo preserva essa opção.

Um exemplo trabalhado

Para tornar isto concreto, imagine uma equipa de apoio a afogar-se em correio recebido. Cada mensagem tem de ser lida, categorizada e encaminhada para a pessoa certa, e o volume ultrapassou as pessoas que o fazem.

O instinto é recorrer a um agente de IA que leia cada mensagem e responda. Passe-a antes pelas perguntas.

Qual é a tarefa, e como a faríamos sem IA? O encaminhamento por palavra-chave e remetente já trata os casos claros. O difícil são as mensagens ambíguas em texto livre — justamente a forma que serve a um modelo.

Quanto custa uma resposta errada? Uma mensagem mal encaminhada custa minutos. Uma resposta automática que inventa uma política de reembolso custa muito mais. Por isso a primeira versão segura sugere uma categoria e um rascunho; quem envia continua a ser uma pessoa.

Como a vamos testar? Algumas centenas de mensagens já resolvidas tornam-se o conjunto de avaliação, incluindo de propósito as desarrumadas e invulgares. Se a categoria sugerida acerta com frequência suficiente para poupar tempo de leitura, ganha o seu lugar.

A funcionalidade que é lançada é estreita: classificar e redigir, envia uma pessoa, as regras por palavra-chave continuam a tratar os casos óbvios, e tudo fica registado para que o conjunto de avaliação continue a crescer.

É um produto mais pequeno, mais seguro e mais barato do que o agente que a equipa imaginou primeiro — e o que tem mais hipóteses de sobreviver ao contacto com caixas de entrada reais.

Decidir o que construir

Usar IA para construir algo e enviar IA lá dentro são duas decisões diferentes. Quem desenvolve pode usar ferramentas de IA enquanto escreve o código e ainda assim entregar um produto que corre com software normal, com funcionalidades de IA, ou com ambos.

Para um produto novo, decida primeiro o fluxo de trabalho útil mais pequeno. Acrescente uma funcionalidade de IA só quando melhora esse fluxo para um utilizador definido e pode ser testada com evidência que a equipa saiba manter.

O plano de produto com IA mais sólido é específico quanto aos seus limites. Nomeia a tarefa, os dados, quem revê, a alternativa, o método de avaliação e os pressupostos de custo antes de a funcionalidade se tornar uma promessa.

Se está a pesar IA contra automação ou software à medida, leve a decisão cedo para a conversa de planeamento. A resposta certa pode ser IA, um fluxo baseado em regras, ou nenhuma tecnologia nova.