Inovação responsável com IA começa na especificação

Para mim, inovação responsável com IA começa ao tornar essas decisões explícitas. Isso inclui entender o resultado esperado, reconhecer os limites do sistema e definir quem responde pelas escolhas. Quanto mais acessível fica a execução, mais atenção precisamos dar à qualidade do pedido.

Em 20 de setembro, a TechCrunch discutiu se líderes da indústria de IA estão dispostos a desacelerar. Esse debate me leva a uma pergunta sobre a rotina das empresas: como estamos decidindo a velocidade dos nossos próprios projetos?

Antes de executar, peça uma especificação

Em um workshop da NewHack, a partir de 32:31, compartilhei uma orientação que considero útil para criar com IA: pedir primeiro a especificação e só depois partir para a execução. A preocupação era evitar uma sequência de pedidos e correções sem clareza sobre a direção do projeto.

Essa especificação pode começar com uma página. Ela deve explicar quem usará a solução, qual tarefa precisa melhorar, quais informações estarão disponíveis e o que ficará fora da primeira entrega. Também precisa registrar as dúvidas que dependem de uma conversa com a equipe.

A própria IA pode ajudar a organizar esse documento. Um pedido possível seria:

Antes de construir, organize a proposta deste projeto. Descreva o problema, os usuários, os dados necessários, os limites e os critérios de avaliação. Separe o que já sabemos das suposições e aponte as decisões que ainda preciso tomar.

Depois, alguém que conhece o processo precisa revisar a resposta. A especificação gerada pode preencher lacunas com hipóteses convincentes. É nessa revisão que descobrimos, por exemplo, se a informação existe, se o fluxo descrito corresponde à realidade e se a equipe concorda com o resultado esperado.

Esse cuidado também ajuda a desenvolver a capacidade das pessoas de trabalhar com IA. Saber formular um problema, reconhecer uma suposição e avaliar uma entrega passa a fazer parte da competência de quem conduz o projeto.

Transforme responsabilidade em critérios observáveis

Expressões como “usar IA com ética” precisam ganhar significado dentro de cada aplicação. Quem pode ser prejudicado por uma resposta errada? Como essa pessoa poderá apontar o problema? Que evidência faria a equipe interromper o teste?

Uma referência para organizar essa conversa é o AI Risk Management Framework 1.0, do NIST. Ele reúne quatro funções: governar, mapear, medir e gerenciar riscos. Também prevê responsabilidades claras e acompanhamento ao longo do ciclo de vida do sistema. É uma referência voluntária, que precisa ser adaptada ao contexto de uso.

Minha proposta, para começar essa discussão na empresa, é responder a cinco perguntas:

• Resultado: qual tarefa deve melhorar e como vamos comparar o antes e o depois?
• Pessoas afetadas: quem usará a solução e quem sentirá as consequências das suas respostas?
• Limites: quais decisões continuam com a equipe e quais informações poderão ser utilizadas?
• Avaliação: que situações precisam ser testadas e quais falhas impedem avançar?
• Responsável: quem acompanha o piloto, recebe problemas e decide sobre sua continuidade?

Essas respostas ajudam a transformar uma intenção em compromissos que podem ser conferidos durante o trabalho.

Um exemplo: organizar solicitações internas

Imagine uma empresa fictícia que recebe pedidos de várias áreas e quer usar IA para organizar essa fila. Um pedido genérico para “automatizar o atendimento” deixa espaço para interpretações muito diferentes sobre o que a ferramenta deverá fazer.

Uma primeira especificação poderia limitar o teste a resumir cada solicitação e sugerir a área responsável. A equipe continuaria decidindo a prioridade e confirmando o encaminhamento. Alterar prazos ou encerrar pedidos ficaria fora desse escopo.

Para avaliar a proposta, seria preciso reunir exemplos de diferentes áreas, incluindo mensagens curtas, pedidos incompletos e termos pouco comuns. Um sistema pode funcionar bem com solicitações do departamento que participou da construção e ter dificuldade com a linguagem de outras equipes.

O teste deveria observar se o resumo preserva as informações importantes, se o encaminhamento sugerido faz sentido e quanto trabalho a revisão exige. Também valeria ouvir quem abriu o pedido: a nova organização tornou o atendimento mais claro? Alguma informação relevante desapareceu no resumo?

Essa avaliação pode mudar o projeto. Talvez a equipe descubra que precisa melhorar o formulário de entrada antes de automatizar a triagem. Talvez a sugestão de encaminhamento seja útil, mas a classificação de urgência ainda exija uma análise mais cuidadosa.

Combine o que permite avançar

Gosto da ideia de separar as decisões sobre experimentar, testar com usuários e ampliar o uso. Cada passagem precisa de uma justificativa compatível com o impacto que a solução terá.

Na experimentação, a equipe pode investigar se a abordagem funciona com exemplos preparados para o teste. No piloto, passa a observar o uso em uma rotina delimitada, com pessoas responsáveis pelo acompanhamento. Para ampliar, precisa avaliar o que aprendeu, quais falhas permanecem e que capacidade terá para atender mais usuários.

Proponho registrar quatro pontos a cada decisão: evidências observadas, limitações conhecidas, responsável e data de revisão. O registro permite que outra pessoa entenda por que o projeto avançou e o que ainda precisa ser acompanhado.

O direito de interromper também deve estar combinado. Se a revisão consome mais tempo do que a tarefa original ou se informações relevantes são omitidas com frequência, a equipe precisa poder ajustar o escopo antes de expandir o uso.

O ritmo também é uma decisão de gestão

No artigo sobre ferramentas internas com IA, contei como um problema pequeno da NewHack virou uma aplicação. Aqui, a reflexão é sobre a forma de conduzir esse movimento quando ele passa a fazer parte do trabalho de uma empresa.

A facilidade de construir abre espaço para mais pessoas proporem soluções. Quero ver esse espaço acompanhado de conversas melhores sobre o que vale fazer, como avaliar e quem precisa participar. Uma boa especificação permite que a equipe encontre divergências enquanto ainda é simples mudar a direção.

Para founders e líderes, vejo uma oportunidade de transformar responsabilidade em prática de gestão: formular melhor os pedidos, ouvir as pessoas afetadas e sustentar decisões com evidências. É uma discussão que quero fortalecer nas iniciativas de inovação corporativa da NewHack, aproximando a vontade de experimentar das condições necessárias para um projeto funcionar no dia a dia.