Instalar inteligencia artificial de forma segura en una empresa no se resuelve eligiendo el modelo correcto. El modelo es la pieza que se cambia; lo que decide el riesgo es la capa que lo rodea. Son siete decisiones de arquitectura, todas anteriores a la elección de proveedor y todas comprobables antes de firmar: dónde vive el dato mientras el modelo trabaja, qué se hace con lo que se envía, quién ve qué, qué puede ejecutar el sistema sin permiso, qué queda registrado, cómo se corta y qué se exige por contrato. Este artículo las desarrolla una a una, con lo que hay que pedir para verificar cada una. Es el paso previo a los seis controles que exigir a un agente en producción.
Qué decide de verdad si una instalación de IA es segura
Lo que decide la seguridad de una instalación de IA es el conjunto de límites que rodean al modelo, no la calidad del modelo. Dos empresas pueden usar exactamente el mismo motor y tener niveles de exposición incomparables: una lo consulta desde una cuenta compartida, con acceso a la unidad de red completa y sin registro; la otra le concede permisos por herramienta, aísla el dato por área y guarda quién preguntó qué.
Esto no es una opinión de diseño: es la razón de que los catálogos de riesgo de IA describan ataques que no tocan el modelo en absoluto —envenenamiento del contexto, extracción por consulta, abuso de permisos heredados— sino la tubería que lo alimenta[2] [6]. La consecuencia práctica para un comprador es cómoda: las siete decisiones se pueden tomar sin entender de redes neuronales, y siguen valiendo cuando el proveedor cambie de modelo el año que viene.
Decisión 1 · Dónde vive el dato mientras el modelo trabaja
Hay tres respuestas posibles y la correcta la fija el dato más sensible que el sistema va a tocar, no la preferencia del área técnica.
En un servicio gestionado el dato sale de la empresa hacia la infraestructura del proveedor del modelo, se procesa y vuelve. Es lo más rápido de poner en marcha y lo que menos carga operativa deja. En una nube privada el modelo corre en infraestructura contratada por la empresa: el dato no se mezcla con el de terceros y la empresa controla la región. En un servidor propio el dato no cruza nunca el borde de la organización.
La pregunta que ordena la decisión no es «¿cuál es más seguro?» sino «¿qué pasa si este dato concreto aparece fuera?». Un histórico de tickets y un expediente laboral no merecen la misma arquitectura, y casi ninguna empresa necesita la misma para todo: lo habitual y lo sensato es mezclar.
Decisión 2 · Qué se hace con lo enviado: entrenamiento, retención y revisión
Aquí se confunden tres cosas distintas y hay que exigirlas por separado y por escrito:
- Entrenamiento: si lo enviado se usa para mejorar el modelo. La respuesta que sirve es un no contractual, no una casilla en un panel.
- Retención operativa: cuántos días se guarda lo enviado para que el servicio funcione —reintentos, depuración, facturación—. Siempre hay alguna; lo que importa es que esté acotada en días y que se pueda pedir su borrado.
- Revisión humana: si personas del proveedor pueden leer contenido para detectar abuso, bajo qué condiciones y con qué trazabilidad.
Un proveedor serio declara las tres con números. Uno que responde «sus datos están seguros» a la pregunta de retención no está tranquilizando: está evitando la pregunta. Esto es materia de contrato, no de arquitectura, y por eso reaparece en la decisión 7.
Decisión 3 · Quién ve qué: aislamiento entre áreas y entre empresas
El aislamiento se diseña antes de cargar el primer documento, porque rehacerlo después obliga a reconstruir el índice entero. La regla es que el filtro de acceso se aplique en la recuperación, no en la respuesta: el sistema no debe recuperar un fragmento que el usuario no podría abrir y luego decidir no mostrarlo. Filtrar al final es una promesa; filtrar al recuperar es un control.
En instalaciones que sirven a varias empresas o a varias áreas, cada fragmento almacenado lleva su etiqueta de pertenencia y toda consulta la lleva también, sin excepción ni modo administrador que la desactive. La prueba de que existe es simple y hay que pedirla: una consulta hecha con las credenciales de un área que devuelva cero resultados sobre un documento de otra, no una explicación de cómo funciona.
Decisión 4 · Qué puede hacer el sistema sin permiso
Un sistema que solo responde texto y uno que además ejecuta acciones pertenecen a categorías de riesgo distintas. En cuanto el sistema puede escribir en una base, enviar un correo o mover un registro, los permisos dejan de ser un detalle de configuración.
Los permisos se conceden por herramienta y por alcance de dato, nunca «al sistema» en bloque, y los parámetros se validan fuera del modelo. Una instrucción en el prompt pidiendo que no haga algo peligroso es una preferencia y se puede sobrescribir con texto suficientemente persuasivo; el límite real vive en la capa que concede el permiso y valida la llamada[5].
Aquí entra el ataque que más sorprende a quien lo ve por primera vez: la inyección indirecta de instrucciones. Todo lo que el sistema lee para trabajar —un correo, un PDF adjunto, una página— es entrada no confiable, porque puede traer instrucciones dirigidas al modelo[4]. Si además tiene permisos amplios, el atacante no necesita entrar en la red: le basta con que alguien le pase el documento.
Decisión 5 · Qué queda registrado, y durante cuánto
El registro tiene que permitir reconstruir una decisión concreta meses después. En la práctica eso significa guardar quién pidió qué, qué contexto se recuperó, qué herramienta se invocó con qué parámetros, qué devolvió, qué decidió el sistema y quién aprobó si hubo aprobación —todo con marca de tiempo y con la versión del modelo y de la instrucción vigentes en ese momento.
Esa última parte es la que casi siempre falta y la que vuelve inútil al resto: sin saber con qué versión de instrucción respondió, el registro cuenta qué pasó pero no permite explicar por qué, que es justo lo que se necesita cuando alguien reclama. Enfoques de verificación por petición como los de una arquitectura de confianza cero encajan de forma natural aquí: cada llamada se autoriza y se anota, en lugar de confiar en que quien está dentro del perímetro puede[3].
Decisión 6 · Cómo se apaga sin apagar la empresa
Un interruptor de parada no es apagar el servidor. Es poder desactivar una herramienta o una función concreta sin derribar el servicio, dejando el sistema en modo degradado —consulta y lectura, sin acciones— mientras se investiga.
Dos condiciones lo separan de un adorno. La primera: el corte tiene que estar al alcance del cliente, no solo del proveedor, porque el incidente puede ocurrir un domingo. La segunda: tiene que haberse ejercitado en simulacro. Un mecanismo de emergencia que nunca se probó no se sabe si funciona, y el día que hace falta no es el día de averiguarlo. Pedir la fecha del último simulacro es una de las preguntas más reveladoras que se le pueden hacer a un proveedor.
Decisión 7 · Qué se exige por contrato
Lo que no está por escrito no es exigible, por muy convincente que fuera la reunión. El contrato debe recoger, como mínimo: la no utilización para entrenamiento; el plazo de retención en días y el procedimiento de borrado; la región de procesamiento; el régimen de subencargados —quién más toca el dato, porque el proveedor del modelo rara vez es el único—; la notificación de incidentes con plazo; el derecho a auditar o, en su defecto, a recibir evidencia periódica; y la portabilidad: qué se lleva la empresa si se va, en qué formato y en cuánto tiempo.
La cláusula que más se olvida es la última. Una instalación de la que no se puede salir con los datos y los índices propios no es un proveedor: es una dependencia. Estas exigencias son las mismas que ordenan la conversación en cómo evaluar a un proveedor de IA.
Las tres arquitecturas, comparadas
| Servicio gestionado | Nube privada | Servidor propio | |
|---|---|---|---|
| Dónde se procesa | Infraestructura del proveedor | Infraestructura contratada por la empresa | Dentro de la organización |
| El dato cruza el borde | Sí | Sí, a un entorno dedicado | No |
| Puesta en marcha | Días | Semanas | Semanas o meses |
| Carga operativa continua | Del proveedor | Compartida | De la empresa: parcheo, copias, vigilancia |
| Control de región | Según el contrato | Alto | Total |
| Encaja bien con | Datos internos de sensibilidad media, volumen variable | Datos regulados con volumen sostenido | Secreto industrial, restricción de salida del dato |
| Riesgo principal | Contrato débil o subencargados no declarados | Configuración de aislamiento mal hecha | Mantenimiento que se abandona con el tiempo |
Cuándo la IA en servidor propio compensa de verdad
El servidor propio compensa cuando el dato no puede salir —por secreto industrial, por una obligación específica del sector o por una decisión de riesgo tomada arriba— y cuando existe alguien que se hará cargo del mantenimiento durante años, no solo de la instalación.
Cuando la razón para elegirlo es otra —desconfianza genérica, o la sensación de que «dentro» es sinónimo de seguro— suele salir mal por una vía predecible: el sistema se instala, funciona, y dieciocho meses después nadie ha aplicado un parche, las copias no se han restaurado nunca y el aislamiento entre áreas quedó pendiente para la fase dos. Un servidor propio desatendido concentra el riesgo en lugar de repartirlo.
La decisión honesta es por dato, no por empresa: lo sensible dentro, lo demás fuera, con el mismo conjunto de siete decisiones aplicado a ambos.
Los tres errores que más vemos
El primero es elegir el modelo antes que la arquitectura. La conversación empieza por cuál es mejor y termina seis semanas después descubriendo que el dato no podía salir del país. Las siete decisiones son anteriores y no cambian al cambiar de motor.
El segundo es confundir el piloto con la instalación. Un piloto con tres personas y datos de prueba no ejercita el aislamiento, ni los permisos, ni el corte. Todo lo que este artículo describe empieza a existir cuando entra el primer dato real de un tercero.
El tercero es prohibir en vez de ordenar. Cuando una empresa prohíbe la IA sin ofrecer una vía autorizada, el uso no desaparece: se vuelve invisible, en cuentas personales y fuera de todo registro. El inventario honesto de lo que ya se usa suele ser el primer entregable útil de cualquier instalación seria, y es el mismo ejercicio que ordena el inventario de componentes de IA.
En Innova y Cree operamos 12 plataformas con IA en producción, y estas siete decisiones son las que tomamos en cada una antes de escribir la primera línea. Lo que publicamos sobre nuestra propia tasa de error y cómo la medimos está en el benchmark público, con su método y sus límites.