Y la realidad es que muy pocas llegan: más del 70 % de los proyectos públicos de inteligencia artificial (IA) no pasan del piloto, según un estudio de 4,372 iniciativas publicado por la consultora tecnológica Nortal.

No es que la tecnología no funcione. Muchas veces el problema es que no se planifica la integración y la operación desde el inicio. La energía se focaliza en la solución, en cómo resolver un caso de uso, y no en pensar en la reutilización de las APIs, la interoperabilidad o los costes reales de uso.

El equipo está centrado en el producto, pero no hay nadie que lidere la etapa de la integración desde el día cero. 

En Gobe hemos visto la importancia de pensar en la “semana 53” incluso antes de la primera reunión. Para no quedarse en el piloto, aquí compartimos algunas claves a tener en mente desde el primer minuto. 

1. Pasar del efecto “wow” a la confianza operativa 

Un producto tiene que emocionar. Tiene que mostrar claramente cómo resuelve un caso de uso. Cómo hace la vida del personal funcionario más fácil. Cómo mejora la vida de la ciudadanía. Cómo permite que el dinero público se gaste donde tiene más impacto.

Sin embargo, el efecto “wow” no es suficiente.

Quien compra la solución tiene que entender los detalles de cómo se opera, cuánto cuesta y cómo se integra en los sistemas. El problema, en general, es que la persona interesada en el producto —generalmente el departamento que tiene que resolver el caso de uso para el que el producto está diseñado— no tiene toda la información. Es más: muchos de los aspectos —y decisiones— relativos a los costes y la integración son responsabilidad de otras personas en otros departamentos (Hacienda, Sistemas…). 

Muchas veces estas áreas sólo se incluyen en la conversación al final, con el piloto probado y cuando se empieza a hablar de escalar. Y aquí es donde surgen los problemas. Desde el lado de la startup, tampoco puede ser solo el CEO o la persona de ventas quien lleve toda la conversación. 

Hay aspectos que hay que afinar que son más “de CTO a CTO”.

Generar estas conversaciones desde muy pronto construye relaciones de confianza operativa y reduce el clásico “sí, pero…” que frena la compra para escalar. 

2. La libreta del CTO: el checklist de preguntas clave

Algo usual es que las empresas esperen a que el cliente haga las preguntas sobre integración. Para realmente vender a escala y no quedarse estancadas en la fase piloto, hay que liderar la conversación sobre integración. El riesgo de no hacerlo es, después de todo el esfuerzo de desarrollo, y tras un éxito con el piloto —con todo el mundo dándose palmadas en la espalda por lo buena que es la solución—, darse de bruces con la realidad de un “NO” a escalar que suena como un portazo. 

¿Cómo evitarlo? Haciendo preguntas que quizá rompan un poco la magia de una reunión donde los equipos están en un buen momento, mostrando una demo, pero que son claves para asegurarse un éxito a largo plazo.

Aquí van siete preguntas que, en nuestra experiencia, son importantes:

1. ¿Cuáles son los sistemas críticos a integrar (ERP, GIS, CRM) y quién los administra?
2. ¿Cuáles son los formatos y diccionario de los datos (JSON/GeoJSON/CSV) que necesitaremos para escalar?
3. ¿Qué API mínima hay documentada?
4. ¿Qué licencias son necesarias? ¿Hay algunas que generen dependencias críticas?
5. ¿Cuáles son las exigencias de interoperabilidad para el intercambio y conservación de información (técnica, semántica y organizativa)?
6. ¿Cumple nuestro producto los requisitos de accesibilidad exigidos?
7. ¿Qué requisitos de seguridad nos exigen?

Este checklist puede ser útil para esa primera o segunda reunión técnica, pero sin duda hay una información que es aún más relevante que todas ellas: ¿quién es el responsable?

Encontrar quién es responsable de cada parte del sistema es clave. No solo para aclarar las dudas de quién tomará la decisión final, sino también para establecer, desde el principio, quién o quiénes serán las personas encargadas de gestionar la relación durante la integración. Y, por cierto, esto también implica determinar quién se encargará del lado de la startup. 

Estas serán las personas que estarán a cargo de preparar un runbook (arranque, monitorización, backup/restore, rotación de claves, escalado de incidencias) y un plan de handover/formación para el equipo del cliente. También es importante acordar, en su caso, un sistema de gestión de tickets y tiempos de respuesta.

3. Nada es gratis: traer a la mesa a quienes gestionan la caja 

Muchas soluciones digitales, especialmente de IA, suelen cobrarse por suscripción o por uso (personas usuarias, tokens, llamadas API, almacenamiento, inferencias…). Esto puede hacer que el coste se dispare al escalar, sobre todo si las métricas no están bien ancladas desde el piloto.

Es clave tener en la mesa a las personas responsables técnicas, pero también a quienes gestionan la caja. Al final, será ese departamento quien decida si el coste del producto a escala entra en presupuesto o no.

De nuevo, aquí van algunos tips prácticos para asegurarse de que no haya sorpresas que arruinen el momento de celebración cuando se decida escalar:

• Definir la unidad de facturación (persona usuaria, llamada, token, GB, etc.) y simular escenarios.
• Establecer alertas y caps (técnicos y contractuales) por entorno/área.
• Desglosar los costes totales de operación: infraestructura (cloud), licencias (OSS/BYOL/propietarias), observabilidad, soporte y continuidad.
• Documentar curvas de escalado (qué pasa si el uso x10) y trade-offs de calidad (por ejemplo, latencia vs. coste).
• Presentar valor y coste juntos. No solo se trata de mostrar los costes, sino también el valor que genera el gasto total.

Hablar de costes demasiado temprano puede ser un poco “anticlimático”, pero el riesgo de no hacerlo es quedarse atascado en la fase de piloto hasta la eternidad. Es mejor tener conversaciones difíciles al principio que evitarlas para luego darse de bruces con la realidad. Además, poner estas cuestiones sobre la mesa desde el principio ayuda a generar confianza. 

La integración no se delega, se lidera

Para una startup que quiere vender al sector público, la apuesta no es ganar la demo y hacer un piloto: la apuesta es estar operando en la semana 53.

En un ecosistema que avanza hacia el govtech 3.0, donde la innovación de startups se integra de verdad en las instituciones y convive con grandes integradores, la ventaja competitiva es la capacidad de integrar y operar.

Delegar la integración implica arriesgarse a quedar en el piloto. Si la startup lidera la conversación desde el inicio, seguramente seguirá ahí para celebrar la semana 53.

‍
‍

‍

* Firma invitada: Fernando Fernandez-Monge. Senior Associate en Bloomberg-Harvard City Leadership Initiative en la Universidad de Harvard e investigador en el Institute for Innovation and Public Purpose en University College London. Una versión anterior de este artículo apareció en el Newsletter DataPolis.