El ecosistema de proveedores de IA en Cantabria y en España ha crecido rápidamente en los últimos años. Hay empresas de software que han añadido “IA” a su catálogo, agencias de marketing digital que ofrecen “soluciones IA”, grandes consultoras con prácticas de IA de tamaño variable y equipos especializados con experiencia real en proyectos de inteligencia artificial.
Para una empresa de Cantabria que busca un socio para un proyecto IA, distinguir entre estas categorías no es sencillo — y elegir mal tiene consecuencias. Este artículo proporciona criterios concretos y preguntas directas para hacer esa evaluación bien.
El problema del ecosistema actual
La barrera de entrada para llamarse “empresa de IA” es muy baja. Cualquier empresa puede añadir IA a su web sin haber completado un solo proyecto en producción. Esto no significa que haya que desconfiar de todos los proveedores, sino que el nombre no es suficiente — los criterios de evaluación tienen que ser más profundos.
El perfil de proveedor más común que no tiene el conocimiento que promete es el que viene de desarrollo de software o de marketing digital y ha añadido herramientas de IA generativa a su oferta sin haber trabajado nunca en proyectos de ML supervisado, datos, integración en producción o gestión del cambio organizativo.
Las preguntas que revelan la diferencia
“¿Cuántos proyectos IA han llevado a producción y siguen en producción hoy?” Esta es la pregunta más importante. No cuántos han empezado, sino cuántos están funcionando en los sistemas reales de un cliente, generando valor medible. Un proveedor que no puede nombrar proyectos en producción con sistemas reales de clientes reales tiene experiencia limitada en lo más difícil: que el proyecto funcione más allá de la demo.
“¿En qué momentos un proyecto IA ha ido diferente a lo esperado y cómo lo gestionaron?” Esta pregunta es muy informativa porque los proyectos IA siempre tienen sorpresas — los datos no tienen la calidad esperada, el modelo no converge como se preveía, los usuarios no adoptan el sistema como se diseñó. Un proveedor experimentado tiene historias de cómo gestionó esas situaciones. Uno sin experiencia real da respuestas genéricas.
“¿Cómo miden el éxito una vez que el sistema está en producción?” Si la respuesta está solo en métricas técnicas (precisión del modelo, tiempo de respuesta) y no en métricas de negocio (horas ahorradas, reducción de errores, mejora en KPIs específicos), el proveedor tiene una perspectiva demasiado técnica para un proyecto que tiene que generar valor de negocio.
“¿Tienen acuerdos comerciales con proveedores de software o herramientas específicas?” Un proveedor con acuerdos de revendedor con herramientas concretas tiene incentivos para recomendarlas independientemente de si son la mejor opción para el caso de uso. La independencia de proveedores de tecnología es una característica relevante en un equipo de implantación IA.
Las señales de alerta en los argumentarios
Algunas frases en los argumentarios de venta de proveedores IA merecen preguntas de seguimiento:
“Implantamos IA en X semanas.” Los proyectos IA bien diseñados no tienen plazos garantizados porque dependen de factores que se descubren durante el proyecto (calidad de datos, complejidad de integraciones). Un proveedor que garantiza plazos muy específicos antes de haber auditado la situación de la empresa o bien está simplificando en exceso el alcance o bien tiene expectativas poco realistas sobre lo que va a encontrar.
“Nuestro ROI documentado es de X veces.” El retorno de un proyecto IA depende del caso de uso, del estado de los datos y del tamaño de la empresa. Citar un retorno genérico sin contexto no informa sobre lo que puede esperar una empresa específica.
“No necesitas cambiar nada de tus sistemas.” La integración de la IA con los sistemas existentes es uno de los aspectos más complejos y costosos. Un proveedor que dice que no hay que cambiar nada puede estar subestimando el trabajo de integración o proponiendo una solución desconectada del resto de la infraestructura.
Qué diferencia a los equipos con experiencia real
Los equipos con experiencia real en proyectos IA tienen características reconocibles. Hacen preguntas sobre los datos antes de proponer soluciones. Explican qué puede salir diferente a lo esperado. No prometen resultados que dependen de factores que todavía no han auditado. Y tienen referencias de proyectos completados — no solo de proyectos iniciados.
También son directos sobre las limitaciones de la IA para casos de uso específicos. Un equipo que dice “para este caso concreto, una solución de analítica estándar puede ser más eficiente que ML” tiene más credibilidad que uno que propone IA para todo.
La importancia de la independencia tecnológica
Para una empresa de Cantabria que contrata un proyecto IA, la independencia del proveedor respecto a las herramientas que recomienda es un criterio relevante. Un equipo que no vende herramientas ni tiene acuerdos de reventa tiene incentivos alineados con los del cliente: recomendar la herramienta más adecuada para el problema, no la que genera más margen al proveedor.
Preguntas frecuentes
¿Es mejor contratar a un proveedor local de Cantabria o a uno con más presencia nacional? La ubicación importa menos de lo que parece en proyectos que pueden hacerse en remoto. Lo que más importa es la experiencia específica en el tipo de proyecto y el sector. Dicho esto, para proyectos que requieren presencia física frecuente (implantaciones en planta, formación presencial), un proveedor local o regional tiene ventajas prácticas.
¿Cómo sé que el proveedor seguirá disponible después del lanzamiento? Es una pregunta legítima. Conviene preguntar cuál es el modelo de soporte y mantenimiento post-lanzamiento, cuántos proyectos están actualmente en fase de mantenimiento y cuál es el equipo que se haría cargo. Un proveedor con muchos proyectos en mantenimiento es señal de que los clientes siguen confiando en ellos una vez que el sistema está en producción.
¿Qué documentación debo pedir al finalizar el proyecto? Documentación técnica del sistema (arquitectura, flujos de datos, parámetros del modelo), documentación de usuario (cómo operar y mantener el sistema), documentación del proceso de reentrenamiento del modelo y las métricas de rendimiento de referencia para detectar degradación en producción.