A IA deixou de ser experimentação para se tornar projeto (e expectativa) nas empresas/organizações. Os vários stakeholders, nomeadamente os acionistas, passaram a pressionar fortemente os CEO para que haja Return on Investment relativo aos investimentos que têm sido feitos. Por sua vez, os CEO investem em plataformas, em políticas e em modelos de governo. E, ainda assim, a adoção teima em falhar, surgindo sempre atalhos e outras formas paralelas de fazer, levando a que o risco aumente e o valor expectável não apareça.O problema raramente é tecnológico. É de design de adoção. É de design organizacional. Ou seja, muitas organizações tratam a IA como mais um projeto de IT ou como uma iniciativa clássica de mudança: aprova-se a ferramenta, fazem-se circular políticas, desenvolve-se formação e mede-se. O que falta é o mesmo que aplicamos aos produtos externos: propostas de valor claras (resultantes de business cases), adaptação ao utilizador e iteração contínua (ágil, de preferência). Isto além do óbvio: colocar IA em cima de processos não-redesenhados e capazes de receber IA conduz a maus resultados.Assim, o end-game começa a ser previsível: muita hesitação, aumento do burnout e saídas e entradas numerosas, além de quezílias entre áreas, departamentos e pessoas. E isto acontece sobretudo na gestão intermédia, onde normalmente se concentra a pressão. E sobe, rapidamente, ao C-level de onde se espera Return on Investment.Da prática, vão surgindo e vão-se lendo algumas lições essenciais (que o digam Jenny Fernandez e Noam Bar-Lev, em artigo recente da Fast Company):A hesitação não devia fazer parte do menu, mas, porque ocorre e se anda para trás e para a frente, transforma-se maioritariamente em risco efetivo. Se a IA complica em vez de simplificar, a adoção acaba por ir quebrando e trava a implementação. O verdadeiro teste é o de “product-market fit interno”: a ferramenta resolve um problema real, com restrições reais, em condições reais? Começar pequeno, remover fricções e partes do processo, clarificar o que permanece humano e proteger tempo de aprendizagem (saber ser consistente, também, na espera, porque ela deriva da aprendizagem e adoção) são condições essenciais.Em vez de impor, é preciso “vender” internamente a necessidade. Ancorar em resultados concretos, i.e., ciclos de adoção mais rápidos, menos retrabalho, maior qualidade e não apenas em features. Cocriar com equipas, integrar nos sistemas já existentes e com processos preparados, investindo na aprendizagem como trabalho core. A confiança nasce quando se entende como os outputs são gerados e onde entra o julgamento humano.A adoção quebra, normalmente, no middle management, porque os gestores têm de mudar a forma de trabalhar, mantendo ou sendo norteados pelos mesmos objetivos. Se o tempo de aprendizagem está a competir com o tempo de entrega, a entrega ganha. Falha a aprendizagem. Os líderes mais eficazes, nestas circunstâncias, ajustam expectativas, recompensam experimentação disciplinada e colocam em operativo apenas o que provou reduzir fricção.A transformação por IA é, assim, e acima de tudo, um desafio de design organizacional, não de IT. E, como design organizacional que é, assenta em pessoas, processos/estrutura. Como dizia há anos, e anos, Chandler, por alguma razão, a estratégia deve comandar a estrutura. Não o contrário. Quando a estrutura é um constrangimento para a estratégia estamos falados. Tudo falha. E falhará.Mais uma vez, aquilo a que estamos a assistir com a IA não é novo. Já foi assim noutras revoluções tecnológicas, acabando por bater de frente com a organização. Portanto, a questão não é a tecnologia. A questão está na organização/empresa e no seu design.