Dossier técnico · Implementación IA · 2026
12 dominios para implementar IA en tu empresa sin sorpresas
O lo pagarás el doble rehaciéndolo en 6 meses. Las preguntas exactas que hacerle a tu equipo y a tu proveedor antes de arrancar.
Cada uno de estos 12 dominios encierra decisiones que comprometen tu cumplimiento legal, tu presupuesto y tu reputación durante años. Ninguno es opcional si la IA va a tocar datos reales o decisiones reales de tu negocio.
La pregunta no es si la IA puede ayudarte. Es si tu equipo puede cubrir estos 12 frentes a la vez, bien, a la primera.
Cómo leer este dossier
Gobernanza, cumplimiento y soberanía del dato
Qué hay que resolver de verdad
- Clasificación del sistema bajo el AI Act (Reglamento UE 2024/1689): riesgo mínimo, limitado, alto o inaceptable. Las obligaciones difieren radicalmente. Calendario vinculante: prácticas prohibidas desde feb-2025, modelos de propósito general (GPAI) ago-2025, sistemas de alto riesgo ago-2026.
- Transferencias internacionales de datos: tras Schrems II (TJUE C-311/18), validar si el proveedor opera bajo el EU-US Data Privacy Framework o requiere Cláusulas Contractuales Tipo (SCC) + un Transfer Impact Assessment. Sin esto, cada prompt con dato personal a un endpoint en EEUU es una transferencia potencialmente ilegal.
- Retención y entrenamiento sobre tus inputs: exigir endpoints zero-retention y un DPA (Data Processing Agreement) con addendum de subprocesadores. Por defecto, varios proveedores se reservan derecho a entrenar con tus prompts.
- Marco de gestión de riesgo auditable: NIST AI RMF o certificación ISO/IEC 42001 (sistema de gestión de IA).
- Seudonimización != exención RGPD: la seudonimización sigue siendo dato personal. Técnicas reales de protección: k-anonimato, privacidad diferencial.
Cómo verificarlo — preguntas para tu proveedor
- "¿En qué país se procesan y almacenan los datos que enviamos al modelo?"
- "¿Tenemos DPA firmado y el proveedor garantiza zero-retention?"
- "¿Qué categoría de riesgo del AI Act aplica a este caso de uso?"
El coste de no hacerlo
Sanción RGPD hasta 20 M EUR o 4% de facturación; sanción AI Act por prácticas prohibidas hasta 35 M EUR o 7%. Más el daño reputacional de una brecha.
Arquitectura de datos y RAG
Qué hay que resolver de verdad
- Estrategia de RAG (Retrieval-Augmented Generation): ingesta, chunking (tamaño y solape de fragmentos), modelo de embeddings, base vectorial (pgvector, Qdrant, Weaviate, Pinecone) y re-ranking de resultados.
- Calidad del dato fuente: un RAG sobre documentación desactualizada o contradictoria produce respuestas desactualizadas o contradictorias.
- Pipeline de actualización: cómo se reindexa cuando cambian las fuentes, con qué frecuencia, cómo se versiona el índice.
- Gestión de permisos a nivel de documento: que el modelo no recupere información que el usuario no debería ver (row/document-level security).
Cómo verificarlo — preguntas para tu proveedor
- "¿Cómo trocea y vectoriza el sistema nuestros documentos?"
- "¿Qué pasa cuando un documento fuente cambia o se borra?"
- "¿Puede un usuario acceder vía la IA a datos que no vería en el sistema original?"
El coste de no hacerlo
Alucinaciones que citan fuentes inexistentes, fugas de información por permisos mal modelados, respuestas sobre datos obsoletos que generan decisiones erróneas con aparente confianza.
Selección y evaluación de modelos
Qué hay que resolver de verdad
- Diferenciar benchmarks públicos (MMLU, etc.) de evaluaciones propias sobre tu caso real: un modelo líder en benchmark puede rendir peor en tu dominio específico.
- Model routing / cascading: usar modelos pequeños y baratos para tareas simples y reservar los grandes para lo complejo.
- Trade-off explícito entre coste, latencia y calidad por caso de uso documentado y decidido.
- Estrategia multi-proveedor para no depender de un único modelo (ver dominio 10).
Cómo verificarlo — preguntas para tu proveedor
- "¿Sobre qué dataset propio habéis medido que este modelo es el adecuado?"
- "¿Por qué este modelo y no uno más barato o más pequeño?"
- "¿Qué latencia y coste por petición tiene en producción bajo carga real?"
El coste de no hacerlo
Facturas innecesarias por usar modelos premium en tareas triviales, o un producto que falla en calidad por usar un modelo insuficiente. En ambos casos, el problema aparece en producción, no en el piloto.
Seguridad específica de IA
Qué hay que resolver de verdad
- OWASP LLM Top 10: prompt injection directa e indirecta, jailbreak, data poisoning del dato de entrenamiento/contexto, fuga de información sensible, model inversion y membership inference, consumo no controlado de recursos.
- Aislamiento de la IA respecto a sistemas con privilegios: que una inyección de prompt no acabe ejecutando acciones destructivas en tu infraestructura.
- Sanitización de entradas y de salidas: no confiar en el output del modelo como si fuera código seguro o dato de confianza.
- Gestión de secretos: que claves y credenciales nunca entren al contexto del modelo bajo ninguna circunstancia.
Cómo verificarlo — preguntas para tu proveedor
- "¿Cómo protege el sistema frente a prompt injection indirecta desde documentos o webs externas?"
- "¿Qué puede llegar a hacer la IA si un atacante controla parte de su entrada?"
- "¿Habéis hecho red teaming del sistema antes de desplegarlo?"
El coste de no hacerlo
Exfiltración de datos, acciones no autorizadas ejecutadas por la propia IA, envenenamiento de respuestas que degrada la calidad del sistema sin que nadie lo detecte.
Calidad de salida, grounding y guardrails
Qué hay que resolver de verdad
- Evals sistemáticas, no "probar a ojo": dataset de evaluación + métricas de groundedness, faithfulness y answer relevance (framework RAGAS u homólogo).
- Grounding obligado: forzar respuestas ancladas a fuente con citación verificable, no respuestas generadas de memoria.
- Abstención: que el sistema diga "no lo sé" cuando la confianza es baja, en lugar de inventar una respuesta plausible.
- Guardrails de entrada y salida: filtrado de PII, validación de formato, límites de alcance temático explícitamente definidos.
Cómo verificarlo — preguntas para tu proveedor
- "¿Con qué métricas y sobre qué dataset medís que el sistema acierta?"
- "¿Qué hace el sistema cuando no sabe la respuesta?"
- "¿Cómo evitamos que responda fuera de su ámbito?"
El coste de no hacerlo
Decisiones tomadas sobre respuestas inventadas, con más confianza y más velocidad que un humano. Reputación dañada en silencio antes de que nadie detecte el problema.
Observabilidad y monitorización
Qué hay que resolver de verdad
- Tracing de cada petición: prompt, contexto recuperado, respuesta, coste, latencia registrados y trazables.
- Evaluación continua en producción, no solo en pre-lanzamiento o en el piloto inicial.
- Detección de drift: el rendimiento se degrada con el tiempo, con cambios en los datos y con cada actualización del modelo base.
- Trazabilidad para auditoría: poder reconstruir por qué el sistema dio una respuesta concreta (requisito además del AI Act para sistemas de alto riesgo).
Cómo verificarlo — preguntas para tu proveedor
- "¿Qué registramos de cada interacción con la IA y durante cuánto tiempo?"
- "¿Cómo detectamos que la calidad está cayendo antes de que se queje un cliente?"
- "¿Podemos explicar a posteriori por qué dio una respuesta concreta en una fecha concreta?"
El coste de no hacerlo
Degradación silenciosa sin alertas, imposibilidad de auditar decisiones automatizadas, incumplimiento de los requisitos de trazabilidad regulatoria del AI Act.
FinOps de IA (control de coste)
Qué hay que resolver de verdad
- Economía de tokens: entender que se paga por token de entrada y de salida, y que el contexto largo dispara el coste de forma no lineal.
- Caching: prompt caching y semantic caching para no pagar dos veces la misma consulta o variantes semánticamente equivalentes.
- Model tiering / cascading: el modelo barato resuelve la mayoría de los casos, el caro solo donde es necesario.
- Topes y alertas de gasto por usuario, por caso de uso y global, configurados antes de llegar a producción.
Cómo verificarlo — preguntas para tu proveedor
- "¿Cuál es el coste por petición y cómo escala si multiplicamos el uso por 10?"
- "¿Tenemos caching y límites de gasto configurados antes del lanzamiento?"
- "¿Qué parte del tráfico podría resolverse con un modelo más barato sin perder calidad?"
El coste de no hacerlo
Un piloto barato que se vuelve económicamente insostenible en producción cuando el uso real llega. El coste de la IA en producción no es lineal con el piloto.
LLMOps (operación del ciclo de vida)
Qué hay que resolver de verdad
- Versionado de prompts y de configuración en un sistema de control, no prompts sueltos hardcodeados en el código.
- CI de evals: cada cambio de prompt o de modelo pasa por la batería de evaluación automatizada antes de desplegarse en producción.
- Despliegue canary y A/B de prompts y modelos para validar antes de exponer al 100% del tráfico.
- Rollback inmediato y documentado a la versión anterior cuando una actualización degrada la calidad en producción.
Cómo verificarlo — preguntas para tu proveedor
- "¿Cómo versionamos y probamos los cambios de prompt antes de producción?"
- "¿Podemos volver a la versión anterior en minutos si algo va mal?"
- "¿Qué pasa con nuestro sistema cuando el proveedor actualiza o deprecia el modelo base?"
El coste de no hacerlo
Un cambio aparentemente inocuo rompe producción sin aviso y sin vuelta atrás rápida. El sistema de IA se vuelve frágil e imposible de evolucionar con seguridad.
Human-in-the-loop y diseño de la decisión
Qué hay que resolver de verdad
- Definir qué decisiones requieren validación humana obligatoria y cuáles pueden automatizarse de forma segura.
- Umbral de escalado claro: cuándo la IA debe pasar el caso a una persona y cómo lo hace en la práctica.
- Diseño de la experiencia para que el humano supervise de forma efectiva sin convertirse en cuello de botella operativo.
- Responsabilidad legal de la decisión: quién responde formalmente cuando la IA se equivoca.
Cómo verificarlo — preguntas para tu proveedor
- "¿Qué decisiones toma la IA sola y cuáles pasan obligatoriamente por un humano?"
- "¿Cuándo y cómo escala un caso a una persona en la práctica?"
- "¿Quién es responsable legal de una decisión automatizada errónea?"
El coste de no hacerlo
Un fallo sistemático ejecutado a escala antes de que nadie lo detecte. La velocidad de la IA amplifica tanto el acierto como el error.
Propiedad intelectual y vendor lock-in
Qué hay que resolver de verdad
- Titularidad de modelo, prompts, código, embeddings e índices: si son del proveedor, migrar te obliga a rehacerlo entero desde cero.
- Portabilidad: poder exportar tus datos, tu base vectorial y tu configuración completa cuando quieras.
- Abstracción del proveedor en la arquitectura para poder cambiar de modelo sin reescribir el producto.
- Licencias del modelo y de los datos de entrenamiento: qué puedes y qué no puedes hacer comercialmente con los outputs generados.
Cómo verificarlo — preguntas para tu proveedor
- "¿De quién son los prompts, el código y los índices que se construyen durante el proyecto?"
- "¿Qué nos costaría cambiar de proveedor de modelo dentro de un año?"
- "¿Podemos exportar todo y llevarnos el sistema a otro proveedor?"
El coste de no hacerlo
Dependencia total de un proveedor único, costes de migración prohibitivos cuando cambia el precio o la calidad del servicio, pérdida de control sobre tu propio sistema.
Integración con sistemas legacy
Qué hay que resolver de verdad
- Integración vía API con ERP, CRM y sistemas internos: latencia adicional, límites de tasa, consistencia de datos entre sistemas.
- Consistencia transaccional: que una acción de la IA no deje datos a medias entre sistemas cuando falla a mitad de camino.
- Idempotencia y reintentos: que un fallo de red no duplique operaciones críticas.
- Mapeo de datos entre el formato que usa la IA y el que exigen tus sistemas internos.
Cómo verificarlo — preguntas para tu proveedor
- "¿Cómo se integra con nuestro ERP/CRM actual y qué latencia añade al proceso?"
- "¿Qué pasa si la IA hace media operación y falla la otra mitad?"
- "¿Cómo evitamos duplicar acciones ante un reintento del sistema?"
El coste de no hacerlo
Datos inconsistentes entre sistemas, operaciones duplicadas, integraciones frágiles que fallan en picos de tráfico y son imposibles de depurar en producción.
Mantenimiento, ownership y transferencia de conocimiento
Qué hay que resolver de verdad
- Transferencia de conocimiento: documentación, runbooks y formación específica para que tu equipo opere el sistema de forma autónoma.
- Ownership claro y documentado: quién mantiene prompts, evals, datos y coste después de que termine el proyecto.
- Plan de actualizaciones: cómo se incorporan mejoras de modelo sin tener que rehacer todo el sistema.
- Deuda técnica de IA: el sistema necesita mantenimiento continuo, no es un proyecto que se entrega y se olvida en un cajón.
Cómo verificarlo — preguntas para tu proveedor
- "¿Quién operará esto en mi equipo cuando termine el proyecto?"
- "¿Qué documentación y formación recibimos al cierre?"
- "¿Cómo se mantiene actualizado a medida que evolucionan los modelos base?"
El coste de no hacerlo
Heredar una caja negra que nadie de tu equipo sabe tocar, y volver a depender del proveedor para cada cambio pequeño. El proyecto que "ya está hecho" se convierte en un pasivo.
¿Lo montas en casa o te acompañamos?
Cada uno de estos 12 dominios encierra decisiones que comprometen tu cumplimiento legal, tu presupuesto y tu reputación durante años. En Hiberus Booster implementamos IA cubriendo estos 12 dominios desde el día uno.
Reserva tu sesión estratégica ->
Miguel QuilezDirector Hiberus Booster