Datos y uso de IA
Qué pasa con los datos y dónde hay una persona en el circuito
Esta página responde las preguntas que hace un área de sistemas antes de aprobar un proyecto. Está escrita para leerse con un responsable de TI al lado, no para impresionar.
El principio
El dato que no hace falta, no se envía. Y lo que se envía, se sabe dónde está, quién lo vio y cuándo se borra.
Esa frase suena bien en cualquier sitio web. Lo que sigue es lo que la hace verificable: cada afirmación de esta página se puede comprobar en el contrato y en la configuración del proyecto.
Lo que esta página todavía no puede afirmar. Los proveedores concretos de modelo, el plazo exacto de retención y la ubicación de los servidores se fijan proyecto por proyecto, en el contrato. No publicamos una lista cerrada porque todavía no existe una.
Seis puntos
Lo que un área de TI necesita saber
1. Dónde se usa IA y dónde hay obligatoriamente una persona
La IA puede
- Clasificar consultas y proponer una categoría.
- Extraer campos de un documento y proponer valores.
- Redactar un borrador a partir de datos ya cargados.
- Resumir un conjunto de textos autorizados.
La persona decide siempre
- Aprobar, corregir o rechazar la clasificación.
- Validar los campos extraídos antes de que entren al sistema.
- Enviar el borrador: el envío nunca es automático.
- Resolver cualquier caso marcado como excepción.
No diseñamos flujos donde una decisión con efecto sobre una persona, un pago o un derecho se ejecute sin revisión humana. Si el cliente lo pide, se explica por qué no lo hacemos y se propone una alternativa que mantenga la revisión.
2. Qué información se entrega a los proveedores de modelos
Solo el fragmento necesario para la tarea acordada. En la práctica eso significa que se define, por cada caso de uso, una lista de campos que se envían y otra de campos que se quedan en su sistema. La lista se acuerda por escrito antes de construir.
No se envían bases completas «para que el modelo aprenda». No hay tal aprendizaje en el uso por interfaz de programación: se envía una consulta y se recibe una respuesta.
Lo que no vamos a afirmar. No escribimos «sus datos nunca se usan para entrenamiento» como frase general, porque la veracidad de esa afirmación depende del producto, del plan contratado y de las condiciones vigentes de cada proveedor. Lo que sí hacemos: revisar esas condiciones antes de elegir el proveedor y dejar por escrito cuáles aplican en su caso.
3. Interfaces, herramientas de terceros y entornos
- Acceso por interfaz de programación con credenciales propias del proyecto, no compartidas entre clientes.
- Entorno separado de producción para pruebas. Si no existe, se construye como parte del alcance, no se prueba sobre datos vivos.
- Datos de prueba: sintéticos o propios anonimizados. Nunca datos personales de terceros en ejercicios ni en demostraciones.
- Herramientas internas: si usamos un servicio adicional (por ejemplo, para procesar documentos), se declara en la propuesta con su función exacta.
4. Control de acceso, retención y limitaciones conocidas
| Aspecto | Práctica |
|---|---|
| Acceso a sus sistemas | Cuentas nominales, permisos mínimos necesarios y revocación al cierre del proyecto. Sin cuentas compartidas. |
| Registro de actividad | Cada caso guarda qué entró, qué propuso el sistema, qué corrigió la persona y cuándo. |
| Retención | El plazo se fija en el contrato. Al término, los datos se devuelven o se eliminan, según lo acordado, con constancia escrita. |
| Limitación conocida | Un modelo puede producir una respuesta plausible y equivocada. Por eso todo resultado con efecto externo pasa por revisión. |
| Limitación conocida | La calidad del resultado depende de la calidad del documento de entrada. Un escaneo ilegible produce una extracción mala, y el sistema debe marcarlo como excepción, no adivinar. |
5. Cómo se mide la calidad y cómo se escala un error
Antes de construir se define un conjunto de casos de prueba con la respuesta correcta esperada. Durante las pruebas se registra cuántos acierta el sistema y cuántos falla. Ese registro se entrega.
En operación, el circuito es este:
- El sistema marca el caso como dudoso, o la persona detecta el error.
- El caso sale del flujo automático y llega a la persona responsable, con plazo definido.
- La persona corrige y deja registro de la corrección.
- Las correcciones se revisan periódicamente para decidir si cambia una regla, un criterio de derivación o el diseño.
Si la tasa de casos derivados a persona es alta, el flujo no está ahorrando trabajo: se declara y se rediseña.
6. Lo que no afirmamos
- No afirmamos que un sistema esté libre de errores. No existe tal sistema.
- No afirmamos cumplimiento total de ninguna norma. Afirmamos qué medidas se tomaron y cuáles no.
- No afirmamos que un proveedor de modelos no use datos para entrenamiento sin indicar producto, plan y condiciones vigentes.
- No afirmamos que la revisión humana elimine el riesgo. Lo reduce y lo deja registrado.
Preguntas que conviene hacer en la primera reunión
- ¿Qué campos exactos se envían al proveedor de modelo?
- ¿Dónde está el entorno de pruebas y con qué datos se llena?
- ¿Quién revisa y qué plazo tiene para hacerlo?
- ¿Qué se registra y por cuánto tiempo?
- ¿Qué pasa si mañana queremos cambiar de proveedor?
Si alguna de estas respuestas no está por escrito antes de empezar, no está resuelta.
Portabilidad y salida
Cómo se sale de un proyecto
El código, la configuración y la documentación quedan en su poder. No hay componentes que solo nosotros podamos mantener. Al cierre se entrega un procedimiento de restauración y se revocan los accesos.
Si decide cambiar de proveedor de modelo, el cambio se hace en la configuración y se vuelve a probar con el mismo conjunto de casos.
Ver los términos del servicioSiguiente paso
¿Su área de sistemas necesita revisar esto antes de avanzar?
Se puede agendar una sesión técnica con esa persona antes de cualquier propuesta. Es más útil que descubrir la objeción en la semana seis.