Casi todas las empresas con las que hablamos han hecho ya su prueba con inteligencia artificial. Un chatbot, un asistente para el equipo de ventas, un piloto para clasificar facturas. Funcionó en la demo, impresionó en la reunión, y luego se quedó ahí.
La conclusión que se saca suele ser «la IA todavía no está madura para nosotros». Casi nunca es eso.
Los modelos llevan tiempo siendo suficientemente buenos para el 90 % de los casos de uso empresariales. Lo que falla está en la capa de alrededor: dónde vive el sistema, con qué datos trabaja, quién responde cuando se equivoca y cómo se paga. Cinco problemas que no son de inteligencia artificial, sino de ingeniería y de organización.
Vamos uno por uno.
1. El proyecto empieza por «primero migramos»
Es el error número uno.
Tu software actual funciona y da dinero. Tiene diez años de reglas de negocio dentro, integraciones con contabilidad, permisos que alguien configuró con criterio y clientes que ya saben usarlo. Y llega un proyecto de IA cuyo primer paso es sustituirlo.
Ningún proyecto que empieza por «primero migramos» llega a producción. Se queda sin presupuesto, sin paciencia o sin el patrocinador que lo impulsaba, porque antes de entregar el primer valor hay que reconstruir algo que ya funcionaba.
Lo que hacen los que sí llegan: ponen la capa de IA encima de lo que ya existe. El agente se invoca desde el software actual mediante su API, o se incrusta como un widget dentro del producto, sin sacar al usuario de donde ya estaba trabajando. Nada se migra. Si el experimento no funciona, se apaga y no ha roto nada.
Esto además cambia la conversación interna: ya no hay que convencer a nadie de tirar su sistema, solo de probar algo al lado.
2. Los datos que harían útil el proyecto no pueden salir de la empresa
El segundo bloqueo aparece en cuanto el proyecto deja de ser un juguete.
Un asistente que no puede leer tus datos no sirve de nada. Pero en cuanto hablas de conectarlo a tu ERP, a tu CRM o a tu histórico de clientes, aparece la pregunta legítima: ¿esto sale de aquí? ¿A dónde va? ¿Quién lo ve?
Y muchas veces la respuesta honesta es que sí sale, que va a servidores de terceros, y que ni el departamento legal ni un cliente con datos sensibles lo van a aceptar. En sectores regulados —sanidad, legal, financiero, industrial con secreto de proceso— eso no se resuelve con una cláusula en un contrato. Hay datos que sencillamente no pueden abandonar tu infraestructura.
Lo que hacen los que sí llegan: deciden desde el principio dónde se ejecuta. Hay tres niveles, y conviene elegirlo conscientemente en lugar de descubrirlo tarde:
API de un proveedor externo
Lo más rápido de montar. Válido para datos poco sensibles, con un acuerdo de tratamiento de datos en regla y garantías de no entrenamiento sobre tu información.
Modelo en tu propia nube
El proceso corre dentro de tu cuenta cloud, con tus recursos y tus permisos. Los datos no salen de tu perímetro.
Modelo self-hosted sobre tu propia GPU
Ni siquiera los prompts salen. Es lo más caro y lo más lento de montar, y a veces es la única opción viable.
La pregunta no es cuál es mejor, sino cuál corresponde a la sensibilidad de cada proceso. Una empresa razonable acaba con los tres conviviendo.
3. El piloto no tiene dueño ni proceso detrás
Un piloto de IA suele nacer de una persona con curiosidad. Funciona mientras esa persona lo empuja. En cuanto cambia de proyecto o se va de la empresa, se apaga.
El fondo del problema es más grande que la IA, y es este: el conocimiento de cómo trabaja tu empresa vive en la cabeza de la gente. Cómo se cualifica un lead, qué revisa un senior antes de enviar una propuesta, qué nunca se hace con un cliente de determinado tipo. Nada de eso está escrito. Cada uno lo hace a su manera y salen resultados distintos.
Cuando intentas automatizar un proceso que nadie ha definido, lo que automatizas es la versión que hacía la persona que estaba delante ese día.
Lo que hacen los que sí llegan: convierten el proceso en un artefacto antes de automatizarlo. No un PDF que nadie abre, sino una definición ejecutable: qué agente hace qué, con qué instrucciones, sobre qué conocimiento, con qué permisos y qué entrega. Algo que se publica, se versiona y se actualiza, de manera que el «cómo trabajamos» deja de depender de que una persona concreta siga en la empresa.
Ese es, por cierto, el beneficio que más se subestima de estos proyectos. No es el ahorro de horas. Es que el conocimiento se queda.
4. El modelo de precio no aguanta el éxito
Este es el que más pilotos mata en la fase de escalado, y casi nadie lo ve venir.
Un piloto con diez usuarios sale barato. Cuando funciona y quieres ponerlo en manos de ciento cincuenta personas, descubres que pagas por usuario, tengas o no tengas actividad. El proyecto que era rentable con diez deja de serlo con ciento cincuenta, justo por haber funcionado.
Y hay una segunda capa: si la herramienta es buena, la usa gente que no la necesita a diario. Pagas licencias completas por consumos mínimos.
Lo que hacen los que sí llegan: cobran por uso real, no por usuario. Y separan lo que se paga por infraestructura de lo que se paga por servicio, de modo que puedas ver cada cosa y optimizar cada cosa. Si tu proveedor te lo factura todo junto, no puedes saber dónde se te va el dinero, y por tanto no puedes reducirlo.
Una prueba rápida antes de firmar: pide que te expliquen qué pasa con tu factura si mañana multiplicas por diez el uso. Si la respuesta es un salto de tramo, no es pago por uso.
5. No hay trazabilidad, así que no hay responsabilidad
Mientras el piloto es un experimento, nadie pregunta. En cuanto toca algo que importa —un presupuesto, una respuesta a un cliente, un asiento contable— aparece la pregunta que lo detiene todo:
Si esto se equivoca, ¿quién responde y cómo lo demostramos?
«Lo decidió el modelo» no es una pista de auditoría. No sirve ante un cliente, ni ante un auditor, ni ante la Agencia Española de Protección de Datos. Y con el AI Act europeo entrando progresivamente en aplicación, esto deja de ser una buena práctica para ser una obligación según el nivel de riesgo del sistema.
Lo que hacen los que sí llegan: diseñan tres cosas desde el día uno.
Modos de autonomía graduables
No es todo o nada. Un agente que redacta un borrador interno puede ir solo; uno que emite una factura, no. Lo razonable es un espectro: ejecución autónoma, aprobación del plan, aprobación de cada tarea, aprobación de cada paso. Y que se ajuste por agente y por encargo, no globalmente.
Límites explícitos
El agente solo puede tocar lo que está en su lista blanca de herramientas y datos. Esto no es solo buena higiene: protege contra instrucciones escondidas dentro de un documento que el agente procesa, un vector de ataque real y poco conocido. Y un techo de consumo, para que un bucle no se convierta en una factura.
Registro completo
Quién pidió qué, cuándo, con qué información, qué herramientas se invocaron y qué resultado salió. Si no puedes reconstruir una decisión seis meses después, no puedes defenderla.
Cómo se ve un proyecto que sí llega
Juntando todo, el patrón es bastante consistente:
- 1
Empieza por un proceso concreto y medible. No «implantar IA en la empresa», sino «clasificar y extraer datos de las facturas de proveedor, que hoy nos lleva doce horas semanales». Si no puedes decir cuánto cuesta hoy, no vas a poder demostrar que ha mejorado.
- 2
Se monta encima de lo que ya existe. Sin migraciones previas.
- 3
Decide dónde viven los datos antes de escribir una línea. Y lo decide el negocio con el asesoramiento técnico, no al revés.
- 4
Define el proceso antes de automatizarlo. Aunque sea la primera vez que alguien lo escribe.
- 5
Nace con permisos, límites y registro. No se añaden después, porque después es cuando ya hay un incidente.
- 6
Se paga por lo que se usa. Para que funcionar bien no lo haga inviable.
Ninguno de estos puntos es especialmente sofisticado. Por eso llama la atención lo poco que se aplican: la conversación sobre IA en las empresas sigue girando alrededor de qué modelo es mejor, cuando la diferencia entre un proyecto que llega y uno que no llega casi nunca está ahí.
De dónde sale este criterio
Conviene que sepas desde dónde escribimos esto. En Namastech llevamos años implantando automatizaciones y proyectos de inteligencia artificial en empresas, y hemos visto de cerca los cinco problemas de arriba. Algunos, en proyectos propios.
De ahí nació Softngeeks, nuestra plataforma de IA para empresas, construida justo sobre estos principios: la capa agéntica se monta encima del software que ya tienes sin migrar nada, todo corre en tu propia nube y con tus datos, los procesos se empaquetan y se versionan en lugar de vivir en la cabeza de alguien, cada agente tiene su modo de autonomía y su registro completo de acciones, y se paga por uso real en lugar de por usuario.
No hace falta que uses Softngeeks para aplicar lo que cuenta este artículo. Pero sí creemos que cualquier plataforma que elijas debería responder bien a estas cinco preguntas, y muchas de las que hay hoy en el mercado no lo hacen.
Preguntas frecuentes
¿Por dónde empiezo si mi empresa no tiene equipo técnico?
Por un diagnóstico de procesos, no por una herramienta. Identificar dos o tres tareas repetitivas, medibles y de bajo riesgo, y evaluar cuál tiene mejor relación entre esfuerzo e impacto. La herramienta se elige después, cuando ya sabes qué tiene que resolver. Es justamente el trabajo de una consultoría tecnológica y de IA.
¿Puedo usar IA con datos de clientes sin incumplir el RGPD?
Sí, si el tratamiento tiene una base legal, hay un acuerdo de tratamiento con el proveedor, el proveedor no entrena con tus datos y no hay transferencias internacionales fuera del Espacio Económico Europeo sin garantías. Cuando la sensibilidad es alta, ejecutar el modelo en tu propia infraestructura elimina buena parte del problema de raíz.
¿Cuánto tarda en verse retorno?
Si el proyecto está bien acotado, semanas y no meses. Los proyectos que tardan un año en dar resultados suelen ser proyectos mal acotados desde el principio.
¿Merece la pena un modelo propio en vez de usar una API?
Solo si hay una razón concreta: datos que no pueden salir, un volumen que hace que la API salga más cara que la infraestructura, o un requisito regulatorio. Como decisión por defecto, no.
¿Hay ayudas públicas para proyectos de IA?
Ha habido líneas estatales que financian tanto el asesoramiento estratégico en IA como la implantación de soluciones, y las convocatorias abren y cierran. Conviene consultar el estado de las ayudas a la digitalización antes de planificar un proyecto contando con una subvención.
¿Qué diferencia hay entre un agente y un chatbot?
Un chatbot responde. Un agente ejecuta: consulta sistemas, invoca herramientas, encadena pasos y produce un resultado. Esa diferencia es también la que explica por qué un agente necesita permisos, límites y registro, y un chatbot casi no.
¿Tienes un piloto de IA parado?
Analizamos por qué no avanza y qué haría falta para llevarlo a producción, o te ayudamos a diseñarlo bien desde el principio. Primera sesión de diagnóstico sin compromiso.
Hablar con nuestro equipo de IA