En la mayoría de automatizaciones, mucho menos de lo que se supone. Un paso que clasifica un ticket necesita el texto del ticket; no necesita el histórico de pagos del cliente que está en el mismo registro. Un paso que extrae campos de una factura necesita la factura; no necesita que los datos bancarios del proveedor vayan en el prompt.
La minimización en la entrada es el control con mayor rendimiento, y es una decisión de diseño, no una declaración de política. Además suele mejorar los resultados, porque un prompt que lleva solo los campos relevantes es un prompt mejor.
¿Dónde se procesa? Qué región, qué subencargados y si la región se puede fijar. Para datos personales de la UE esto es una cuestión legal, no una preferencia.
¿Qué se conserva y cuánto tiempo? Los prompts y las salidas son datos. Pregunte qué se almacena, dónde y cómo se borra.
¿Se usa para entrenar? No debería, y la respuesta debería apuntar a una cláusula contractual y no a una tranquilización.
¿Quién puede verlo? Modelo de acceso, registro de auditoría y si el personal del proveedor puede leer su contenido en escenarios de soporte.
¿Qué pasa si nos vamos? Qué recupera, en qué formato y qué se destruye. Pregúntelo antes de firmar, no al final.
Tres se repiten lo bastante como para planificarlos. Primero, debe existir y estar documentada una base jurídica para el tratamiento — normalmente interés legítimo o contrato — y esa determinación le corresponde a usted como responsable, no a nosotros. Segundo, si la automatización toma una decisión con efecto jurídico o similarmente significativo sobre una persona, el artículo 22 limita el tratamiento totalmente automatizado, que es una de las varias razones por las que la revisión humana significativa viene incorporada por defecto y no como opción.
Tercero, el borrado tiene que funcionar de extremo a extremo. Una solicitud que elimina un registro del sistema de origen pero lo deja en un índice vectorial o en un log no está satisfecha. Lo que se construya tiene que saber olvidar, y eso es un requisito de diseño desde el primer día, no una funcionalidad posterior.
Para cualquier sistema que busque en sus documentos, la capa de recuperación debe heredar su modelo de acceso existente. Un sistema capaz de responder cualquier pregunta desde cualquier documento es un fallo de control de acceso con una interfaz amable, y suele aflorar la primera vez que alguien pregunta por el sueldo de un compañero.
Por eso preferimos construir sobre un modelo de acceso que ya exista. Inventar uno durante un proyecto de automatización significa que el proyecto pasa a ser dueño de un diseño de permisos, un compromiso mucho mayor de lo que parece al principio.
Su infraestructura y su región donde importa. Procesamiento fijado a la región; ningún movimiento de datos por conveniencia del desarrollo.
Sin entrenamiento con su contenido. Configurado en el proveedor y recogido por contrato.
Registro completo de accesos. Quién o qué leyó qué registro, cuándo y para qué paso.
Revisión humana en todo lo relevante. Devoluciones, acciones sobre cuentas, pagos y salidas clínicas o jurídicas quedan con una persona por diseño.
Flujos de datos documentados. Un diagrama de qué se mueve a dónde, entregado con el desarrollo, que además es lo primero que pedirá su DPO.
Trabajamos con prácticas conformes al RGPD, y con controles SOC 2 cuando el cliente los necesita. Cuando un cliente necesita una certificación formal nuestra y no de nuestros proveedores de infraestructura, lo decimos con claridad en lugar de dar a entender una acreditación que no tenemos.
Cómo se tratan, conservan y borran los datos, en los propios términos del sitio.
Donde las restricciones son más estrictas y el alcance se limita deliberadamente al back office.
Dónde se toman en el proyecto las decisiones de seguridad y residencia.
Usamos cookies solo para analítica: para ver desde qué páginas llegan las consultas. Nada más, y nada antes de que aceptes. Política de cookies