Todo proveedor de IA que atiende a organizaciones reguladas dice la misma frase en la conversación sobre protección de datos: con nuestra arquitectura, quedas en cumplimiento. La parte técnica suele ser verdadera. El problema es que el cumplimiento no es una propiedad del software, es una decisión sobre el tratamiento.
Esta pieza ocupa este lugar en la serie porque ejecutar en el entorno del cliente convierte parte de la pregunta jurídica en una pregunta de ingeniería, y porque conviene separar lo que esa conversión alcanza de lo que sigue en manos de la organización.
La diferencia entre reducir la superficie y estar en cumplimiento
Procesar dentro de la propia infraestructura elimina una clase de problema, no todas. La excepción viene antes que la ventaja. La pieza de apertura de esta serie ya describió lo que ocurre con un flujo apuntado a un proveedor externo. Lo que corresponde agregar aquí es el resto de esa frase: la salida no cambia solo la ruta de la red, cambia el encuadre jurídico de ese tratamiento. Ese tramo pasa a involucrar a un tercero, con contrato propio, con una finalidad que tiene que estar cubierta y, si el procesamiento ocurre en otro país, con una regla de transferencia internacional. En muchos casos la salida es la decisión correcta: contenido que no es confidencial, una tarea en la que decide la calidad del modelo, un proveedor que el área jurídica ya aprobó. Lo que no hace es sacar ese tratamiento de tu rendición de cuentas.
Hecha la salvedad, dos preguntas cambian de naturaleza. La transferencia internacional pasa a depender de dónde está la infraestructura del cliente, y no de la ruta que eligió el proveedor. La lista de quién toca el dato pasa a levantarse desde dentro, en vez de depender de lo que el proveedor declara. Las dos son preguntas que la organización responde por sí sola.
Nada de eso vuelve legítimo el tratamiento. Una organización puede procesar dentro de casa exactamente el dato que no tendría autorización para procesar en ningún lugar. Las normas de protección de datos, la LGPD brasileña o el GDPR europeo entre otras, no empiezan preguntando dónde está el servidor. Empiezan por la finalidad del tratamiento, y la arquitectura no responde por la finalidad. Si la respuesta del proveedor afirma que la decisión ya está tomada, es venta.
Lo que sigue siendo trabajo de la organización
Una pieza que se detuviera en la sección anterior sería material publicitario. Hay al menos tres frentes que la instalación en el entorno del cliente no resuelve, y uno de ellos existe justamente porque la instalación ocurre allí.
Autorización. La finalidad, la autorización y la minimización son anteriores al software. Ejecutar dentro de casa no autoriza a procesar lo que no se podría procesar en ningún lugar. La pregunta es quién autorizó cada contexto, no quién logró indexarlo.
Ciclo de vida. La retención, la eliminación y la atención a las solicitudes de los titulares siguen siendo obligación de la organización, y se vuelven más difíciles con la IA de por medio. La pregunta es qué pasa con lo que se derivó del documento: el fragmento que entró en un índice, el vector que representa ese texto, el historial de la conversación que citó el contenido. Ningún proveedor responde eso por instalación.
Operación de la infraestructura. El deber de adoptar medidas de seguridad y de responder por ellas sigue siendo de la organización cuando la infraestructura es suya. Parte de lo que un proveedor de nube acreditaba con informes y certificaciones pasa a acreditarlo tú, con evidencia producida en tu propio entorno. Una organización sin equipo de infraestructura puede quedar con una protección peor que la de un entorno de terceros bien operado, y sigue siendo la responsable de esa protección. Lo que esa operación cuesta como rutina es asunto de la tercera pieza de esta serie. Aquí el punto es más estrecho: instalar dentro de casa mueve la responsabilidad, no la elimina.
Cuando la exigencia llega desde fuera de la organización
Esos frentes se los reclama alguien, y no siempre quien contrató. En el sector público la pregunta sobre cómo se tomó una decisión llega antes que la pregunta sobre la calidad de la respuesta, y llega desde fuera del equipo del proyecto: un órgano de control, una auditoría interna, el ciudadano al que le negaron una solicitud. Eso suma exigencias a las de calidad, no las sustituye. Además de saber si la respuesta es buena, el organismo necesita saber si cada consulta deja registro y qué acervo sustentó una salida específica.
Ninguna de las dos se resuelve después. Aparecen con el proyecto ya en producción, cuando responder exige reconstruir lo que nadie registró. Por eso pertenecen a la etapa de diseño, y la etapa de diseño termina antes de que empiece la prueba de concepto.
Qué preguntar antes de la prueba de concepto
Estas preguntas valen para cualquier proveedor, nosotros incluidos:
- ¿Qué datos salen de mi entorno en operación normal, cuáles salen por elección mía y cómo veo esa diferencia antes de aprobar?
- Si necesito eliminar el dato de una persona, ¿qué pasa con los índices, los vectores y los historiales derivados?
- ¿Puedo demostrar después qué acervo sustentó una respuesta específica y quién tenía acceso a él?
- ¿En qué punto una persona tiene que aprobar antes de que el sistema produzca un efecto sobre alguien?
- ¿Qué de esta lista viene instalado y qué sigue siendo diseño mío?
La quinta es la que más desarma una presentación comercial, porque la respuesta honesta suele ser larga.
Lo que la arquitectura cambia en la pregunta
Ejecutar en el entorno del cliente desplaza la pregunta jurídica, no la responde. Donde antes se preguntaba qué hace el proveedor con el dato, ahora se pregunta qué decidió tratar la organización, con qué finalidad y con qué registro. Es una pregunta mejor, porque quien tiene la obligación de responderla también tiene los medios para hacerlo. No es una pregunta más fácil, y la arquitectura no la decide por nadie.
Junto con ese control llega el trabajo que venía incluido en el contrato de un proveedor de nube. Asumes funciones que eran de otra persona, y asumes también el costo de mantenerlas. La quinta pieza de esta serie trata de ese costo y del modelo de cobro que impone. La sexta trata de lo que sigue funcionando cuando el contrato termina.