Preguntas de seguridad y cumplimiento que hacerle a un proveedor de automatización

Pregunta ocho cosas, en este orden: dónde residen físicamente nuestros datos y si comparten infraestructura con otros clientes; si alguno de ellos entrena un modelo, el tuyo o el de un tercero; a qué puede acceder la automatización, actuando como quién, y quién aprueba los cambios en ese acceso; qué se registra, durante cuánto tiempo, y quién puede leer o modificar el registro; qué subencargados tocan los datos; qué ocurre en las primeras horas de un incidente y cuándo se nos informa; qué estamos autorizados contractualmente a inspeccionar; y qué evidencia respalda cada una de las siete respuestas anteriores. Todo lo demás en un cuestionario de seguridad estándar es una variación de una de esas.

Las respuestas en sí no son la parte útil. Cualquier proveedor competente responderá bien a las ocho en una llamada comercial. La verdadera prueba es si puede presentar la evidencia que respalda cada respuesta: un diagrama de tenencia, la cláusula del contrato, una exportación de la política IAM real, una muestra de registro de auditoría con campos reales, la lista actual de subencargados, un informe de un incidente pasado, derechos de auditoría firmados, todo ello sin dramas de escalado y sin un mes de retraso. Un proveedor cuyos controles son reales tiene todo esto guardado en una carpeta. Un proveedor cuyos controles viven en la cabeza de un ingeniero enviará una respuesta pulida al cuestionario y luego se quedará callado cuando le pidas la exportación. Nuestras respuestas están en nuestra página de seguridad, y la documentación de respaldo está en nuestro centro de confianza. Exígenos el mismo estándar que le exigirías a cualquier otro.

Residencia de datos y tenencia

La residencia son dos preguntas, no una. Primero: ¿en qué países reposan los datos, y en cuáles transitan o se procesan? Las herramientas de soporte, las copias de seguridad, la agregación de registros y las réplicas de recuperación ante desastres suelen aterrizar en una región distinta a la de la carga de trabajo principal, y ahí es donde los compromisos de residencia se rompen silenciosamente. Segundo: ¿el entorno es de un solo inquilino, está separado lógicamente dentro de una infraestructura compartida, o es realmente compartido? La mayoría de la automatización gestionada funciona con separación lógica, lo cual está bien para la mayoría de las cargas de trabajo, pero hay que decirlo con claridad en lugar de dejar que "dedicado" haga un trabajo ambiguo en una diapositiva.

Exige detalles concretos sobre dónde van los datos en reposo, en las copias de seguridad, en los registros y en cualquier servicio de modelo u OCR de la cadena. Si el proceso toca registros regulados, pregunta qué ocurre cuando el proveedor necesita que un ingeniero de soporte en otra zona horaria depure de noche una ejecución fallida. La respuesta honesta suele ser que alguien accede a un entorno que contiene tus datos. Eso es aceptable si está acotado, registrado y limitado en el tiempo. No es aceptable si nadie lo ha pensado.

Entrenamiento con tus datos

Pregúntalo como una cadena, no como una única pregunta, porque el proveedor rara vez es la única parte implicada. ¿El proveedor entrena con tus datos? ¿El proveedor del modelo de tu proveedor entrena con los datos enviados a través de su API? ¿Algún componente de terceros integrado —extracción de documentos, transcripción, traducción, una base de datos vectorial, un SDK de analítica— retiene las entradas para mejorar el producto? Cada eslabón necesita su propia respuesta, y cada una debe constar por escrito, ya sea en el contrato o en una política referenciada que no pueda cambiar sin previo aviso.

Ten cuidado con dos puntos débiles habituales. Uno es "no entrenamos con datos de clientes", una frase que cubre al proveedor pero no a su proveedor ascendente. El otro es la retención para monitorización de abusos, que es legítima pero implica que tus documentos persisten en algún lugar durante un periodo. Pregunta cuál es la ventana de retención, si hay procesamiento de retención cero disponible en tu plan, y quién puede acceder al contenido en búfer durante esa ventana. Si la respuesta solo existe de palabra, no es una respuesta.

Modelo de acceso y mínimo privilegio

La automatización es un conjunto de credenciales con una tarea. La pregunta crítica es qué pueden hacer esas credenciales más allá de la tarea. Pide las cuentas de servicio concretas que usará la automatización, los alcances o roles exactos que tienen asignados, y si son de solo lectura allí donde podrían serlo. Luego haz la pregunta más difícil: ¿quién puede cambiar esos alcances, y ese cambio genera una alerta hacia tu lado o solo hacia el del proveedor?

Exige cuentas humanas nominales para cualquier persona del lado del proveedor que pueda acceder a producción, con SSO y MFA forzados a través de tu proveedor de identidad siempre que sea posible; nada de credenciales compartidas, nada de una cuenta de integración genérica que usan tres personas. Pregunta cómo se concede, se revisa y se revoca el acceso del personal del proveedor cuando alguien deja su equipo, y con qué rapidez se te informa. Pregunta si existe acceso permanente a producción o si se solicita por incidente y caduca. El acceso permanente, amplio y sostenido en manos de un elenco rotativo de contratistas es la debilidad más habitual que vemos, y también la más fácil de corregir antes de que empiece un proyecto.

Registro y auditabilidad

Toda acción automatizada debe poder reconstruirse después por alguien que no estuvo presente. Pide ver una línea de registro real, no una descripción de cómo funciona el registro. Debe identificar qué se ejecutó, sobre qué registro, con qué entradas, bajo qué identidad, a qué hora, qué se decidió, y qué aprobó o no aprobó una persona. Si el registro deja constancia de que una ejecución tuvo éxito pero no de qué cambió, no puedes investigar nada ni puedes responder a un auditor.

Luego pregunta dónde vive el registro y si el proveedor puede editarlo. Los registros que solo existen dentro de la plataforma del proveedor, editables por el propio proveedor, son evidencia de buena intención y nada más. Pregunta si los registros pueden transmitirse a tu propio SIEM o almacén de registros, en qué formato y con qué latencia. Pregunta por la retención: cuánto tiempo en línea, cuánto tiempo archivado, y si eso coincide con tus obligaciones de conservación de registros en lugar del valor predeterminado del proveedor. Para los pasos de aprobación, pregunta si el sistema captura la identidad de quien aprueba y el estado que realmente vio, algo que importa mucho más que una marca de tiempo cuando alguien impugna una decisión más adelante.

Subencargados

Pide la lista actual, por escrito, con el rol de cada parte y los datos que ve. Luego haz la pregunta de proceso que realmente te protege: ¿cómo se te notifica antes de añadir un nuevo subencargado, con cuánta antelación, y tienes derecho a oponerte, y qué ocurre si te opones? Una lista de subencargados sin mecanismo de notificación de cambios es solo una foto fija de un objetivo en movimiento.

Presta especial atención a todo lo que esté en la capa de IA. Los proveedores de modelos, los servicios de análisis de documentos y los proveedores de voz son subencargados aunque parezcan infraestructura, y son los que con más probabilidad cambiarán a mitad de contrato a medida que el proveedor ajusta coste y calidad. Si el proveedor no puede decirte hoy qué proveedor de modelo procesa tus documentos, tampoco podrá decírtelo el próximo trimestre.

Respuesta a incidentes

Sáltate el documento de política y pide la cronología. ¿Quién decide que algo es un incidente? ¿En qué plazo se te notifica, y ese plazo empieza a contar en la detección o en la confirmación? ¿Quién te llama, y tienen tu contacto fuera de horario ya hoy, en lugar de después del papeleo? ¿Qué se comunica en la primera actualización, cuando los hechos todavía son escasos?

Luego pregunta por el fallo específico de la automatización que la mayoría de las políticas ignoran: qué ocurre cuando el sistema hace correctamente lo incorrecto. Una regla mal configurada que registra cientos de asientos contables erróneos o envía correos a los clientes equivocados no es una brecha de seguridad, así que puede que ni siquiera active el proceso de incidentes, y sin embargo es el modo de fallo que con mucha más probabilidad vas a experimentar. Pregunta cómo se detiene una ejecución a mitad de camino, cómo se identifica y revierte el trabajo ya realizado, y quién tiene la autoridad para pulsar el interruptor sin esperar a una reunión. Un proveedor que ya haya construido automatización en producción responderá a esto de inmediato, porque lo ha vivido.

Derecho de auditoría y qué evidencia pedir

Las cláusulas de derecho de auditoría se conceden habitualmente y rara vez se ejercen, lo cual está bien: la cuestión es dejar establecido que la inspección es posible, con un aviso razonable, sin tener que renegociar. Lo que deberías ejercer realmente es la versión más ligera: una revisión anual de informes, exportaciones de configuración y listas de acceso, además de la posibilidad de inspeccionar después de un incidente. Pregunta qué está dispuesto a aceptar el proveedor en un acuerdo firmado, y trata una negativa rotunda como información valiosa.

Los informes de cumplimiento son necesarios, pero con frecuencia se sobreinterpretan. Un informe cubre un alcance definido durante un periodo definido, y ese alcance suele ser más estrecho que el producto que estás comprando. Lee la sección de alcance y las excepciones, no el logotipo.

Cuando la respuesta es "no automatizar esto todavía"

Diremos esto en una llamada de alcance, y preferimos decirlo pronto. Espera cuando el proceso subyacente no tiene un responsable que pueda definir qué aspecto tiene un resultado correcto: la automatización hace que un proceso indefinido falle más rápido, no mejor. Espera cuando la única forma de completar el trabajo es conceder a una cuenta de servicio un acceso amplio y permanente a un sistema de registro porque nadie sabe acotarlo; arregla primero el modelo de permisos, porque de todos modos lo vas a necesitar. Espera cuando los datos de origen son tan inconsistentes que cada ejecución requiere interpretación humana, lo cual es un problema de calidad de datos disfrazado de automatización.

Y espera cuando el proceso tiene una consecuencia regulatoria que todavía no puedes acreditar. Si un auditor preguntara quién aprobó una decisión y tu diseño candidato no puede responder eso en un registro, automatizarlo te hace retroceder por mucho esfuerzo manual que ahorre. Los factores de coste aquí son sobre todo puntuales: rediseño de accesos, limpieza de datos, definir las vías de aprobación y excepción. Suelen ser pequeños en comparación con el trabajo de desmontar una automatización que produjo resultados no auditables durante meses.

Cómo hacer la revisión sin frenar el proyecto

Envía las ocho preguntas antes de la demo, no después de redactar el contrato. Pide la evidencia con el mismo calendario que la conversación comercial, para que la seguridad no sea un obstáculo de última hora. Decide de antemano qué respuestas son requisitos firmes y cuáles son preferencias, porque un proveedor fuerte en control de accesos y flojo en residencia puede seguir siendo la opción correcta para un proceso que nunca toca datos regulados, y lo contrario también es cierto. Luego acota la primera automatización lo suficiente como para que el modelo de seguridad sea realmente comprobable en producción y no solo teórico, que es precisamente cómo estructuramos nuestros proyectos por esta misma razón.

Si quieres poner a prueba estas preguntas frente a un proceso que estás considerando, o frente a una propuesta que ya tienes sobre la mesa, habla con nosotros. Repasaremos las ocho contigo, te diremos dónde están las lagunas, y te diremos con claridad si la recomendación honesta es esperar.

Preguntas que nos hacen sobre esto