Google anunció el 15 de junio nuevas inversiones en centros de datos y apoyo comunitario en Alabama. La noticia va de infraestructura, empleo y energía en Estados Unidos. A primera vista queda lejos de una pyme de Donostia - San Sebastián o de una empresa industrial de Gipuzkoa. Pero hay una lectura bastante útil para cualquier organización que quiera meter IA en procesos reales: la capacidad de cómputo ya no es un detalle técnico que se decide al final.
Cuando una empresa empieza con IA, la conversación suele ir directa al modelo: qué LLM usar, qué agente probar, qué herramienta conecta con el CRM. Tiene sentido, porque es la parte visible. Pero en cuanto el piloto toca documentación interna, atención al cliente, ventas, soporte o análisis de datos, aparecen preguntas menos vistosas y más importantes: dónde se procesa la información, cuánto cuesta usar el sistema cada día, qué pasa si hay picos de demanda y qué datos no deberían moverse sin control.
Ese es el gancho de negocio. No se trata de montar infraestructura por presumir. Se trata de no descubrir demasiado tarde que el caso de uso funciona, pero la arquitectura no aguanta el uso real.
Por qué una noticia de centros de datos importa a una empresa local
Las grandes tecnológicas están invirtiendo en capacidad porque la IA consume cómputo de forma distinta a una aplicación web clásica. Un asistente que responde sobre documentos internos no solo muestra una pantalla. Recupera contexto, llama a un modelo, genera una respuesta, quizá consulta herramientas y deja trazas.
Para una empresa de Gipuzkoa esto se traduce en decisiones concretas:
- Si el asistente lo usan diez personas o doscientas.
- Si responde a consultas internas o a clientes en un canal público.
- Si trabaja con datos comerciales, contratos, incidencias o documentación técnica.
- Si la respuesta debe llegar en segundos o puede esperar.
- Si el coste por uso encaja cuando el sistema deja de ser una demo.
No hace falta diseñar como una multinacional. Sí hace falta hacer números y poner límites desde el principio.
El error habitual: validar la demo y olvidar el día dos
Un piloto pequeño puede ir bien con una cuenta cloud estándar, unos documentos de prueba y poco tráfico. El problema llega cuando el equipo lo adopta. Empiezan las consultas repetidas, se añaden departamentos, se conectan CRM o ERP, y alguien pregunta si también puede atender una parte del soporte externo.
Ahí se ve si el proyecto estaba preparado. Si no lo estaba, aparecen costes imprevisibles, lentitud, dudas sobre privacidad y una sensación incómoda: la IA funciona, pero no sabemos si podemos confiar en ella como proceso.
Por eso conviene separar dos preguntas. La primera: "¿la IA resuelve el problema?". La segunda: "¿podemos operarla con seguridad, coste razonable y disponibilidad suficiente?". Las dos importan. La segunda suele llegar tarde.
Datos: qué puede ir a cloud y qué no
No todos los datos tienen el mismo riesgo. Una ficha pública de producto no exige el mismo cuidado que un contrato, una tabla de precios, un parte de fabricación o una incidencia con datos de cliente.
Antes de elegir arquitectura conviene clasificar el material en cuatro grupos sencillos:
- Información pública o comercial.
- Documentación interna de bajo riesgo.
- Datos de clientes, proveedores o empleados.
- Conocimiento sensible: contratos, márgenes, propiedad intelectual o documentación crítica.
Con esa clasificación se decide si basta una nube bien configurada, si conviene usar servicios en regiones europeas, si hace falta una nube privada o si parte del procesamiento debe quedarse en local. No es una decisión ideológica. Sale del dato y del uso.
Coste: mirar el uso real, no el precio de una prueba
El coste de IA no se entiende mirando una sola llamada al modelo. En un proyecto de empresa hay más piezas: extracción de documentos, búsqueda semántica, almacenamiento, logs, evaluación, monitorización, integraciones y horas de revisión humana.
Un caso sencillo puede ser barato al principio y caro si se usa mal. Por ejemplo, un agente que resume cada correo completo aunque solo necesite dos campos. O un RAG que manda demasiado contexto al modelo porque los documentos están mal troceados. O un flujo comercial que genera diez borradores cuando bastaría uno con buena información.
La buena noticia es que muchas fugas se corrigen con diseño: limitar contexto, cachear respuestas internas cuando tenga sentido, elegir modelos pequeños para tareas repetitivas, medir consumo por área y registrar qué flujos generan más coste.
Disponibilidad: cuándo importa que la IA no se caiga
No todos los proyectos necesitan alta disponibilidad desde el primer día. Si un asistente interno para consultar manuales se cae una mañana, molesta. Si el agente cualifica leads de una campaña activa o ayuda a soporte con clientes esperando respuesta, el impacto cambia.
La pregunta práctica es: qué proceso se para si el sistema no responde. Si no se para nada crítico, el piloto puede ser simple. Si afecta a ventas, atención al cliente, operaciones o producción, conviene pensar en contingencias:
- Qué hace el equipo si el modelo no responde.
- Qué respuestas quedan guardadas o auditadas.
- Qué tareas requieren revisión humana antes de ejecutarse.
- Qué proveedor o región se usa para cada tipo de dato.
- Qué métricas avisan antes de que el coste o la latencia se disparen.
No es burocracia. Es evitar que una herramienta útil se convierta en otro punto frágil del negocio.
Primer paso recomendado para empresas de Gipuzkoa
Si tu empresa quiere usar IA en documentación interna, ventas, soporte u operaciones, yo empezaría con un mapa muy concreto. Nada enorme. Una tabla de una página con cinco columnas:
- Proceso que se quiere mejorar.
- Datos que necesita la IA.
- Usuarios que lo usarán.
- Riesgo si falla o responde mal.
- Coste esperado cuando lo use el equipo real.
Con eso ya se ve qué caso merece un piloto y qué arquitectura mínima necesita. A veces basta con un flujo sencillo en cloud. Otras veces conviene diseñar desde el principio permisos, trazabilidad, proveedores europeos, modelos pequeños o una parte local.
En Umintia ayudamos a empresas de Donostia - San Sebastián, Gipuzkoa y Euskadi a aterrizar proyectos de IA sin sobredimensionar la infraestructura ni quedarse cortos cuando llega el uso real. Si quieres revisar un caso concreto, escríbenos a info@umintia.com. Un diagnóstico inicial sirve para separar una prueba cómoda de un sistema que puede funcionar de verdad.