A IA está a transformar os contratos SaaS em compromissos de infraestrutura.

O SaaS deveria ser o antídoto para a dependência de fornecedores tradicionais. Pague mensalmente, receba atualizações contínuas, cancele com um pré-aviso de 90 dias. Todo o modelo foi construído com base na flexibilidade. Mas a IA está silenciosamente a desmantelar essa promessa — não alterando os termos na primeira página do seu contrato, mas mudando a natureza do que está realmente a comprar.

Quando o seu fornecedor de serviços na nuvem inclui um agente de IA no seu pacote de produtividade, o seu fornecedor de CRM integra um assistente de IA que aprende com os dados do seu pipeline, ou o seu fornecedor de ERP implementa um fluxo de trabalho automatizado que automatiza as decisões de aquisição, essa «assinatura de software» começa a parecer-se muito com um contrato de fornecimento de energia. Teoricamente, pode mudar de fornecedor, mas o custo real de o fazer é agora muito mais elevado do que qualquer um prevê na altura da renovação.

«O contrato que assinou no ano passado não tem nada a ver com aquele com que está a lidar hoje — e a maioria das organizações ainda não se apercebeu disso.»

Este é o principal desafio que os responsáveis pelas áreas de compras, finanças e tecnologia das empresas enfrentam neste momento: as funcionalidades de IA estão a transformar as relações SaaS, passando de uma lógica de subscrição para uma lógica de infraestrutura. As organizações que reconhecerem esta mudança atempadamente conseguirão negociar melhores condições, criar pilhas de tecnologia mais resilientes e evitar uma nova geração de dependência de fornecedores. As que não o fizerem ver-se-ão presas a condições que nunca tencionaram aceitar.

Para compreender o quanto as coisas mudaram, é útil recordar por que razão o SaaS revolucionou o software instalado localmente, em primeiro lugar. A característica determinante não foi o custo mais baixo — foi a fungibilidade. Se o seu fornecedor de software de RH aumentasse os preços ou ficasse para trás em termos de funcionalidades, poderia realizar uma avaliação comparativa, migrar os seus dados e estar operacional numa nova plataforma no espaço de um trimestre. O custo de mudança era real, mas era limitado e previsível.

As práticas de aquisição das empresas adaptaram-se em conformidade. Os prazos contratuais mais curtos tornaram-se a norma. A tarifação baseada na utilização proporcionou aos compradores flexibilidade para expandir a escala sem assumirem compromissos excessivos. Os modelos que privilegiam a fase piloto permitiram às organizações avaliar a adequação antes de assinarem contratos plurianuais. Todo o manual de aquisições foi ajustado com base no pressuposto de que os fornecedores de SaaS eram, em grande medida, intercambiáveis.

Isto funcionava porque o valor de um produto SaaS assentava no acesso às funcionalidades do software — um conjunto de funcionalidades, uma interface de utilizador, uma biblioteca de integração. O software não o conhecia. Não aprendia consigo. Os seus dados residiam no sistema, mas a inteligência do sistema não se desenvolvia em torno deles. Mudar de sistema significava transferir registos estruturados de uma base de dados para outra, e não desmantelar a compreensão que um modelo treinado tinha do seu negócio.

A transição do modelo de subscrição para o de infraestrutura não está a ocorrer através de um único mecanismo. Trata-se da convergência de três forças estruturais que se reforçam mutuamente. Cada uma delas é significativa por si só. Em conjunto, representam uma nova realidade em matéria de aquisições.

1. Gravidade dos dados

Quando uma funcionalidade de IA é treinada, ajustada ou continuamente aperfeiçoada com os seus dados proprietários — os registos dos seus clientes, os seus tickets de apoio ao cliente, as transcrições das suas chamadas de vendas —, a migração deixa de ser um problema de exportação de dados e passa a ser um problema de arquitetura de dados.

A migração tradicional de SaaS envolvia a transferência de registos estruturados. A migração na era da IA implica perguntar: para onde vai o contexto aprendido pelo nosso modelo? Em muitos casos, a resposta é que não vai para lado nenhum. Fica com o fornecedor, incorporado num sistema que nenhum formato de exportação consegue capturar. O seu investimento na melhoria do desempenho dessa IA — a rotulagem, os ciclos de feedback, a formação personalizada — representa custos de mudança que não aparecem em nenhum balanço, mas que são muito reais quando tenta sair.

«Mudar de fornecedor de serviços na nuvem implica uma reestruturação da infraestrutura. Mudar para SaaS nativos de IA exige, cada vez mais, o mesmo.»

2. Integração de fluxos de trabalho

Os copilotos e assistentes de IA não se limitam a executar tarefas — eles transformam a forma como as pessoas trabalham. Quando uma equipa de vendas passa doze meses a trabalhar em conjunto com uma IA que redige os seus e-mails de acompanhamento, identifica riscos nas transações e recomenda os próximos passos, essas pessoas reestruturam os seus hábitos profissionais em função dos resultados da IA. O custo de transição já não é apenas técnico. É comportamental e organizacional.

Trata-se de uma forma de dependência que é mais difícil de quantificar do que a migração de dados, mas potencialmente mais significativa. Os colaboradores perdem produtividade sempre que um fluxo de trabalho muda; quando a mudança implica desmantelar um sistema de IA com o qual evoluíram em conjunto ao longo dos anos, essa perda de produtividade é profunda, prolongada e difícil de reverter.

3. Dependência do modelo

A terceira força, e a mais subestimada, é a dependência do modelo. Quando os agentes de IA tomam decisões de grande impacto — redigir contratos, classificar os pedidos de apoio ao cliente, gerar previsões financeiras —, as organizações tornam-se dependentes não só da plataforma de software, mas também do comportamento, da calibração e dos padrões de raciocínio de um modelo específico.

A sua equipa aprende a confiar nos resultados de um determinado modelo. Os seus processos são construídos em torno das taxas de erro e dos casos extremos desse modelo. As suas estruturas de governação são ajustadas às suas tendências específicas. Quando esse modelo é atualizado — ou quando considera mudar para um concorrente cujo modelo se comporta de forma diferente — não está apenas a mudar de software. Está a introduzir incerteza sistemática nas decisões nas quais a sua organização aprendeu a confiar.

Reconhecer essa mudança é o primeiro passo. Para agir em conformidade, é necessário alterar a forma como as equipas de compras, finanças e tecnologia abordam as relações com serviços SaaS baseados em IA — começando já na fase de negociação do contrato, e não após a implementação.

Os contratos requerem condições adequadas ao nível das infraestruturas

A portabilidade dos dados, a transparência dos modelos e os acordos de nível de serviço (SLA) significativos devem ser negociados com o mesmo rigor que as organizações outrora reservavam aos contratos de centros de dados. Isto implica disposições explícitas para a exportação não só dos seus dados, mas também dos seus artefactos de treino, das configurações dos seus modelos e da sua lógica de integração. Implica direitos de auditoria sobre a forma como os seus dados são utilizados para melhorar os sistemas de IA do fornecedor. E implica acordos de nível de serviço (SLA) que abranjam a qualidade e a consistência dos resultados da IA, e não apenas o tempo de atividade da plataforma.

A avaliação de fornecedores deve ter em conta as fases anteriores do processo

Avaliar um fornecedor de SaaS nativo de IA significa agora avaliar o seu fornecedor de IA, as suas políticas de atualização de modelos, as suas práticas de governação de dados e o seu plano de desenvolvimento de produtos — e não apenas o seu conjunto atual de funcionalidades. Um fornecedor que utilize um modelo de base de um fornecedor com ciclos de atualização agressivos apresenta um perfil de risco diferente daquele que oferece estabilidade na versão do modelo. Estas questões devem ser incluídas no pedido de proposta (RFP), e não na análise pós-implementação.

O custo total de saída é o novo indicador

As equipas de aquisição que ainda avaliam o SaaS com base no custo das licenças e na adequação das funcionalidades estão a ignorar o principal fator de risco. O indicador que importa na era da IA é o custo total de saída: o custo económico total de abandonar um fornecedor, incluindo a migração de dados, a reciclagem profissional do pessoal, a reestruturação de processos e o conhecimento institucional atualmente incorporado nos resultados da IA. Calcular este valor antes da assinatura — e não após a renovação — é o que distingue os compradores mais experientes dos restantes.

A governança deve abranger o comportamento da IA

Quando uma IA faz uma recomendação com consequências, a questão da responsabilização não se resolve por si só. Os contratos devem especificar compromissos relativos às versões do modelo — para que as organizações saibam quando a IA subjacente às suas decisões está a mudar. Devem incluir obrigações de intervenção humana para decisões que excedam os limites definidos. E devem estabelecer direitos de auditoria suficientemente robustos para garantir a conformidade regulamentar em setores onde as decisões geradas por IA serão alvo de um escrutínio cada vez maior.

«As organizações que encararem o AI-SaaS como infraestrutura desde o início conseguirão negociar melhores condições, criarão pilhas de tecnologia mais resilientes e evitarão uma nova geração de dependência de fornecedores.»

Nada disto constitui um argumento contra a adoção da IA. Os ganhos de produtividade são reais, as vantagens competitivas estão a acumular-se e as organizações que ficam à margem enquanto outras implementam a IA em grande escala acabarão por pagar um preço bem diferente.

Mas a adoção e a intencionalidade não estão em conflito. As organizações que estão a ter sucesso com a IA neste momento não estão a evitar assumir compromissos — estão a fazê-lo de forma deliberada, aplicando desde o início um rigor digno de infraestruturas às suas relações com os fornecedores. Estão a negociar a portabilidade dos dados antes mesmo de terem produzido quaisquer dados que valham a pena migrar. Estão a modelar os custos de mudança antes de ficarem presos a um fornecedor. Estão a colocar as questões difíceis sobre a governança dos modelos antes de a IA ser integrada nos seus fluxos de trabalho.

As organizações que vão enfrentar dificuldades não são aquelas que avançaram demasiado depressa na IA. São aquelas que avançaram ao ritmo das assinaturas, enquanto os seus compromissos se deslocavam silenciosamente para a escala da infraestrutura.

A sua próxima renovação de SaaS não é um contrato de software. É uma decisão arquitetónica para os próximos cinco anos. A sua equipa está a encarar isso dessa forma?

Considerações sobre aquisições: SaaS na era das assinaturas vs. SaaS na era da IA

Lista de verificação com 5 perguntas para a análise de contratos de IA-SaaS

Antes de assinar ou renovar qualquer contrato de SaaS com funcionalidades de IA, a sua equipa deve ser capaz de responder a estas perguntas.

• Este contrato inclui direitos explícitos de portabilidade de dados caso decidamos rescindir o contrato?
• Que modelo(s) de IA está(ão) na base destas funcionalidades e qual é a política do fornecedor relativamente a atualizações de modelos ou mudanças de versão?
• Quais são os nossos direitos de auditoria relativamente aos resultados e recomendações gerados pela IA?
• Já calculámos o custo total da mudança — incluindo a migração de dados, a reciclagem profissional do pessoal e a reformulação dos processos?
• O nosso contrato especifica obrigações de intervenção humana em relação às decisões da IA que tenham consequências?