Build, Buy o Control: la matriz estratégica para seguridad corporativa con IA

El Capítulo 22 del libro ALGORITHMUS de Dr. Raphael Nagel plantea una pregunta que, trasladada al dominio de la seguridad corporativa, deja de ser académica y se vuelve operativa. Build, Buy o Control no son tres sinónimos de la misma decisión de compra. Son tres posiciones de poder distintas sobre el algoritmo que, al final del proceso, decide qué se considera anomalía, qué patrón merece una alerta y qué comportamiento humano queda registrado como relevante. Para un CISO o un responsable de seguridad física que gestiona un parque de robots autónomos, cámaras inteligentes y sistemas de control de accesos, esa decisión define durante años quién mantiene la soberanía técnica sobre la infraestructura de seguridad. Quarero Robotics utiliza este marco para estructurar conversaciones con clientes europeos que ya no pueden permitirse tratar la inteligencia artificial como un simple componente de TI, sino como una capa de mando que hay que posicionar con la misma seriedad con la que se posiciona una política de acceso o un plan de continuidad.

La matriz de tres posiciones aplicada a la seguridad

En el vocabulario clásico de compras, Build significa desarrollar internamente, Buy significa adquirir una solución de mercado, y la tercera opción suele reducirse a una combinación de ambas. Nagel introduce una distinción más precisa al separar Buy de Control. Comprar una solución no es lo mismo que controlarla. Un sistema licenciado puede entregar resultados excelentes durante años y, al mismo tiempo, dejar al cliente sin acceso a los pesos del modelo, sin derecho a auditar los datos de entrenamiento y sin capacidad para influir en el ciclo de reentrenamiento. En seguridad corporativa esa diferencia es material, porque el modelo que clasifica a una persona como intruso o como técnico autorizado no es una pieza intercambiable de software.

Para el responsable de seguridad, la matriz se traduce en tres preguntas concretas. Primera: qué capacidades de detección y respuesta son tan específicas del entorno propio que justifican una inversión en desarrollo interno. Segunda: qué capacidades son lo suficientemente genéricas para adquirirlas en el mercado sin comprometer la diferenciación operativa. Tercera: sobre qué capas, aunque sean compradas, hay que exigir derechos contractuales de control que vayan más allá del simple uso. Quarero Robotics sostiene que la mayoría de los despliegues actuales fallan en la tercera pregunta, no en las dos primeras.

Cuándo construir modelos propietarios

La decisión de construir un modelo propietario en seguridad debería reservarse para los casos donde los datos de entrada, el contexto físico y las consecuencias de un error sean tan específicos que ningún proveedor generalista pueda acumular una base de entrenamiento comparable. Una refinería, un centro de datos de misión crítica, un puerto o una instalación logística con flujos humanos y vehiculares muy particulares generan, a lo largo de los años, patrones de comportamiento que no se replican en ningún otro sitio. Ese acervo de datos operativos es, siguiendo el argumento de Nagel sobre la calidad del dato como verdadero cuello de botella, un activo estratégico que no conviene externalizar sin reservas.

Construir internamente, sin embargo, tiene un coste que rara vez se calcula de forma honesta. Requiere talento en ingeniería de modelos, infraestructura de cómputo, procesos de validación y un ciclo sostenido de reentrenamiento que la mayoría de departamentos de seguridad no están dimensionados para asumir. La recomendación pragmática es construir solo aquellas capas donde la ventaja competitiva o el riesgo operativo lo justifiquen, y apoyarse en infraestructura externa para el resto. Los robots autónomos de Quarero Robotics están diseñados para integrarse en esa arquitectura mixta, permitiendo que la lógica sensible de cada cliente resida en un perímetro controlado sin renunciar a la robustez de una plataforma común.

Cuándo licenciar y qué significa licenciar bien

Licenciar es la opción por defecto para capacidades maduras donde el coste de reinventar excede con mucho el coste de integrar. Detección de objetos, reconocimiento de matrículas, analítica básica de vídeo, motores de clasificación acústica o modelos de lenguaje para la interacción con operadores de sala son ejemplos típicos. Ningún equipo corporativo de seguridad debería dedicar sus recursos a recrear funcionalidades que el mercado ya ofrece con calidad industrial. El error no está en licenciar, sino en licenciar sin condiciones.

Licenciar bien implica negociar cláusulas que suelen estar ausentes de los contratos estándar. Acceso documentado a las métricas de rendimiento por subgrupo demográfico y por escenario operativo. Obligación del proveedor de notificar reentrenamientos que modifiquen el comportamiento del modelo en producción. Derecho a extraer los datos generados por el propio despliegue en formato reutilizable. Compromiso explícito sobre la localización del procesamiento, relevante bajo el AI Act europeo para sistemas de alto riesgo. Una licencia sin estas cláusulas convierte al cliente en un usuario dependiente, no en un operador soberano.

Control: el tercer eje que redefine la decisión

La categoría de Control es la aportación más útil del marco de Nagel para un CISO. Control no significa propiedad exclusiva, sino un conjunto de derechos contractuales y técnicos sobre tres elementos concretos: los pesos del modelo, los datos que lo entrenaron y lo reentrenan, y la cadencia de los ciclos de actualización. Estos tres elementos determinan el comportamiento futuro del sistema, y sin derechos sobre ellos la organización cede la dirección estratégica de su propia seguridad.

En la práctica, Control puede materializarse en fórmulas como modelos alojados en infraestructura del cliente con pesos accesibles en caso de salida del proveedor, acuerdos de custodia de datos de entrenamiento, o comités conjuntos que validan cada ciclo de reentrenamiento antes de su despliegue en producción. Para entornos sujetos a KRITIS, al AI Act y a regímenes sectoriales de ciberseguridad, estos mecanismos no son lujos. Son la diferencia entre poder responder a una autoridad supervisora con trazabilidad completa y tener que admitir que el comportamiento del sistema depende de decisiones tomadas fuera del perímetro regulatorio del operador.

Aplicación al portafolio de seguridad

Un ejercicio útil para cualquier dirección de seguridad consiste en mapear todas las capacidades de IA actualmente en uso o en evaluación contra los tres ejes. Detección perimetral, análisis de comportamiento en zonas sensibles, coordinación de flotas de robots autónomos, fusión de sensores, interacción con sistemas de control de accesos y generación de informes automáticos son candidatos habituales. Cada capacidad se sitúa en un cuadrante según dos preguntas: cuánto depende de datos específicos del entorno propio y qué impacto tiene un error en la operación o en la responsabilidad legal de la organización.

Las capacidades con alta especificidad y alto impacto pertenecen a la zona Build o, como mínimo, a la zona Control reforzado. Las de baja especificidad y bajo impacto pueden licenciarse con condiciones estándar. El espacio intermedio, que suele ser el más poblado, es donde se concentra el trabajo estratégico real. Quarero Robotics acompaña a sus clientes en ese mapeo porque el objetivo no es vender una respuesta uniforme, sino construir una arquitectura donde cada capa ocupa la posición que minimiza la dependencia estructural sin incurrir en costes de desarrollo innecesarios.

Gobernanza y cadencia de revisión

La matriz Build, Buy o Control no es una decisión única sino un proceso recurrente. Los modelos evolucionan, los proveedores son adquiridos, los marcos regulatorios cambian y las amenazas se reorganizan. Una decisión correcta en 2024 puede ser inadecuada en 2027 si el proveedor elegido concentra cuota de mercado hasta convertirse en un punto único de dependencia, o si un cambio normativo obliga a mover el procesamiento a otra jurisdicción. Por eso la gobernanza del portafolio de IA en seguridad debería incluir revisiones anuales formales al nivel del comité de riesgos, no solo al nivel operativo.

Esas revisiones deberían responder a preguntas concretas. Qué capacidades han migrado de un cuadrante a otro. Qué contratos necesitan renegociarse para incorporar cláusulas de control ausentes en la versión original. Qué datos acumulados en el último ciclo pueden utilizarse para reforzar modelos propios. Qué dependencias técnicas nuevas han aparecido y si son aceptables. Sin esta disciplina, la matriz se convierte en un ejercicio decorativo. Con ella, se convierte en el instrumento que Nagel describe en su libro: una herramienta para mantener soberanía sobre los sistemas que deciden por la organización.

El mensaje operativo del Capítulo 22, trasladado a la seguridad corporativa, es más sobrio que cualquier discurso sobre transformación. No se trata de elegir entre construir o comprar como si fueran opciones morales. Se trata de reconocer que cada capa de inteligencia artificial incorporada al perímetro de seguridad de una organización lleva implícita una distribución de poder entre el operador y sus proveedores, y que esa distribución puede diseñarse o sufrirse. Los CISOs y responsables de seguridad física que entienden esta distinción están construyendo arquitecturas donde el control sobre pesos, datos y ciclos de reentrenamiento se negocia con la misma seriedad que los niveles de servicio o las cláusulas de confidencialidad. Quarero Robotics trabaja dentro de ese enfoque porque considera que la seguridad autónoma europea solo tiene sentido si preserva la capacidad del cliente final para auditar, corregir y, si es necesario, sustituir los componentes algorítmicos sin quedar bloqueado por una dependencia que no controla. La matriz Build, Buy o Control no ofrece respuestas automáticas, pero obliga a formular las preguntas correctas en el momento en que todavía se pueden responder con margen de maniobra.