Subir documentos en un chatbot de IA: verificación de archivos, protección de datos y handoff

Un icono de carga en la ventana del chat parece sencillo: seleccionar archivo, hacer pregunta, recibir respuesta. Sin embargo, técnica y editorialmente, en este punto comienza un proceso independiente. Un documento puede contener datos personales, contenidos activos, estructuras de archivos manipuladas, escaneos ilegibles o instrucciones que un modelo de lenguaje no debe tratar como hechos fiables. Por eso, subir un documento en un chatbot de IA requiere límites claros antes de la transmisión, varias estaciones de verificación después y una salida comprensible si algo no funciona.

La siguiente guía está dirigida a equipos de sitios web, soporte y producto. No describe la función de un solo fabricante, sino una visión objetiva y sólida: los usuarios saben antes de subir el archivo qué está permitido; el sistema separa la recepción, la verificación de seguridad y la evaluación del contenido; los errores se mantienen comprensibles; los casos sensibles se transfieren de forma controlada a una persona.

La carga de archivos necesita un propósito claro

No comience con una lista interminable de formatos compatibles, sino con unas pocas tareas. ¿Debe el chatbot explicar los datos de una factura, resumir documentación técnica o añadir una captura de pantalla a una solicitud de soporte? Para cada tarea debe quedar claro qué contenidos se necesitan, qué decisión puede tomar el sistema y cuándo es obligatoria una revisión humana.

Esta vinculación al propósito evita que la función de subida se convierta en un almacén de documentos general. También ayuda en el diseño: un comprobante para una reclamación requiere avisos y reglas de conservación distintas a las de una descripción pública de producto para una base de conocimiento. La guía existente sobre el entrenamiento con preguntas frecuentes, documentos y contenidos web aborda la base de conocimiento curada; aquí, en cambio, nos ocupamos de los archivos que los visitantes envían durante una conversación en curso.

Hacer visibles los tipos de archivo, tamaños y cantidades permitidas

Los usuarios deben ver las reglas antes de que se abra el diálogo de selección de archivos: formatos permitidos, tamaño máximo, cantidad máxima y si se aceptan archivos comprimidos o protegidos con contraseña. Utilice una lista blanca que solo admita los formatos necesarios para el negocio. "Todos los documentos" no es un requisito útil.

El atributo HTML accept mejora la selección en el navegador, pero no es un control de seguridad. MDN señala expresamente que los usuarios a menudo pueden eludir la restricción de selección y que, por lo tanto, la verificación debe realizarse en el servidor. Así, la interfaz puede ofrecer extensiones de archivo adecuadas, mientras que el servidor evalúa de forma independiente la extensión, el tipo MIME notificado, la firma real y la estructura.

No aceptar nombres de archivo ni metadatos sin verificar

Un nombre original puede contener caracteres especiales, rutas del sistema, cadenas muy largas o información confidencial. Para el almacenamiento interno, el sistema debe asignar un identificador aleatorio propio y tratar el nombre visible solo como información de visualización depurada. Los metadatos integrados también pueden contener nombres, datos del dispositivo o ubicaciones. Si se necesitan estos datos, debe deducirse del propósito del proceso.

La Cheat Sheet de subida de archivos de OWASP recomienda, entre otras cosas, una lista blanca de extensiones, verificación independiente del tipo, nombres de archivo seguros, límites de tamaño, almacenamiento fuera de la raíz web y protección contra subidas no autorizadas. Ninguna comprobación individual es suficiente por sí sola; lo ideal es una cadena de pequeños controles verificables.

Separar recepción, verificación de seguridad y evaluación

Un archivo recibido no debería estar disponible inmediatamente en el chat. Un flujo de trabajo sólido conoce al menos tres estados: recibido, en revisión y liberado para evaluación. Durante la comprobación, el archivo permanece en un área aislada. Solo tras superar el control, el proceso de extracción obtiene acceso. Deben evitarse las URL públicas directas o las rutas de almacenamiento predecibles.

Análisis de malware y comprobación de estructura

Según el nivel de riesgo, el proceso debe incluir análisis de virus o sandbox, verificación de firmas y, en archivos PDF u ofimáticos adecuados, desarmado y reconstrucción de contenido (CDR). Los archivos comprimidos, anidados o con una compresión inusualmente alta necesitan sus propios límites, ya que pueden consumir recursos excesivos o atacar a los analizadores sintácticos. Los escáneres y las bibliotecas deben estar actualizados y configurados de modo que un tiempo de espera o un error de análisis no se interpreten como una aprobación.

La extracción de texto es un estado de calidad independiente

Un archivo seguro puede seguir siendo inútil: un escaneo torcido, una foto con reflejos, una nota manuscrita o un PDF sin capa de texto extraíble. Por ello, el sistema debe informar por separado si el archivo se aceptó de forma segura y si el contenido se pudo leer correctamente. Una baja calidad de extracción no debe ocultarse inventando información adicional.

Formular errores de forma precisa y orientada a la acción

"Error al subir el archivo" deja en el aire qué hacer a continuación. Es mejor mostrar mensajes diferenciados: formato no compatible, archivo demasiado grande, protección con contraseña detectada, verificación de seguridad no superada, texto no legible o procesamiento no disponible temporalmente. El mensaje no debe revelar detalles internos del escáner ni de la infraestructura, pero sí ofrecer una alternativa de corrección segura.

Las pautas WCAG 2.2 exigen una identificación y descripción textual de los errores de entrada detectados automáticamente. La explicación del Criterio de conformidad 3.3.1 Identificación de errores destaca que no basta con volver a mostrar el formulario. Para el chat, esto significa: nombrar el nombre del archivo o la posición de carga, explicar el error en texto y ofrecer una opción concreta para reemplazarlo, eliminarlo o transferirlo al soporte.

Comunicar el progreso de forma accesible

Con archivos grandes se generan tiempos de espera. Una barra visual por sí sola no ayuda a todos los usuarios. Los cambios de estado como "Subida en curso", "Verificación de seguridad", "Leyendo contenido" y "Listo" deben ser reconocibles de forma programática sin desplazar el foco del teclado de forma imprevista. La explicación del W3C sobre WCAG 4.1.3 Mensajes de estado menciona explícitamente el progreso, el éxito y los errores como información de estado relevante.

La opción de cancelar debe permanecer accesible. Tras la cancelación, debe ser visible si la transmisión realmente se detuvo y si se descartó cualquier copia parcialmente recibida. En dispositivos móviles, el nombre del archivo, el progreso y el botón de eliminación deben disponerse de manera que no tapen la casilla de entrada ni la navegación principal.

Explicar la protección de datos antes de la subida

A través de un aviso previo a la transmisión, se deben responder estas preguntas: ¿Para qué se utiliza el archivo? ¿Quién puede verlo? ¿Cuánto tiempo permanecerá almacenado? ¿Se utilizará su contenido para entrenar un modelo? ¿Cómo se puede eliminar el archivo? Las políticas de privacidad generales siguen siendo importantes, pero no sustituyen al aviso contextual directamente en el punto de carga.

El artículo 5 del Reglamento General de Protección de Datos (RGPD) incluye, entre otros, la limitación de la finalidad, la minimización de datos y la limitación del plazo de conservación. En la práctica, esto significa: solicitar solo los documentos necesarios, evitar páginas o metadatos innecesarios, fijar un plazo de eliminación justificado y verificar técnicamente el borrado efectivo. Esto no constituye asesoramiento legal individual; los deberes concretos deben evaluarse para cada caso de uso.

Separar los chats públicos de los procesos protegidos

Un chat público en un sitio web no es automáticamente el lugar adecuado para contratos, documentos de identidad, datos de salud o extractos bancarios. Para gestiones sensibles, la conversación debe trasladarse a una zona autenticada o a un canal seguro establecido. La publicación sobre chatbot de IA público frente a portal de clientes muestra cómo separar la identidad y el acceso a los datos.

Incluso dentro de un área con sesión iniciada se aplica el principio de menor privilegio. Un agente de soporte puede necesitar ver un recibo, pero no requiere acceso permanente a todos los documentos subidos a una cuenta. Los accesos, descargas y eliminaciones deben registrarse de forma trazable sin copiar innecesariamente el contenido del documento en los registros de analítica.

El contenido del documento sigue sin ser de total confianza

Un archivo aprobado está procesado técnicamente, pero desde el punto de vista del contenido todavía no es una fuente de autoridad. Los documentos pueden estar desactualizados, ser contradictorios o haber sido manipulados intencionadamente. También pueden contener instrucciones diseñadas para forzar la fuga de datos o elusión de reglas en el modelo. Trate el texto extraído como contenido no confiable (untrusted content), sepárelo de las reglas del sistema y limite las herramientas y el acceso a datos.

La guía sobre Prompt Injection en chatbots para sitios web explica esta frontera para RAG y herramientas. Para las subidas de archivos, se añade lo siguiente: las respuestas deben hacer referencia a pasajes identificables del documento, explicitar la incertidumbre y no inventar datos faltantes en decisiones críticas.

Human Handoff con un paquete de contexto reducido

La transferencia a un humano es necesaria cuando la comprobación de seguridad falla repetidamente, la extracción no es fiable, la identidad o los permisos no están claros, o se requiere una decisión técnica fuera del alcance del chatbot. Solo deben transferirse los datos que el agente humano necesite para continuar: motivo de la consulta, estado del archivo, referencia segura del documento, mensaje de error concreto, datos ya confirmados y el siguiente paso deseado.

El archivo no debe enviarse adicionalmente por correo electrónico sin cifrar solo porque el chatbot no pudo leerlo. Un proceso de human handoff bien planificado conserva el contexto, la responsabilidad y las expectativas sin duplicar innecesariamente contenidos sensibles.

Medir con eventos, no con el contenido de los documentos

Para la mejora del producto, a menudo basta con registrar eventos estructurados: selección iniciada, subida cancelada, tipo rechazado, límite de tamaño alcanzado, comprobación de seguridad superada, extracción insuficiente, opción de transferencia elegida y eliminación confirmada. Los nombres de archivo, el texto extraído y los datos personales no deben acabar en las analíticas ni en los registros de errores.

Evalúe las métricas de éxito y protección de forma conjunta. Una alta tasa de archivos subidos no sirve de nada si muchos usuarios no entienden qué documento se espera o si terminan subiendo datos sensibles en un chat público. Por lo tanto, también son importantes la tasa de corrección, los abandonos tras el aviso de privacidad, el porcentaje de archivos ilegibles, el tiempo transcurrido hasta mostrar un error claro y la resolución exitosa tras el handoff.

Lista de verificación antes del lanzamiento

• ¿Se ha definido un propósito claro y un tipo de documento permitido para cada caso de uso?
• ¿Son visibles el formato, el tamaño, la cantidad, la protección por contraseña y la retención antes de seleccionar el archivo?
• ¿Verifica el servidor la extensión, el tipo MIME, la firma, la estructura y los límites de tamaño independientemente del navegador?
• ¿Se han implementado la cuarentena, el análisis de malware, la extracción y la aprobación como estados independientes?
• ¿Reciben los usuarios mensajes de error y de progreso precisos y accesibles?
• ¿Se trasladan las gestiones sensibles a un canal autenticado o gestionado por humanos?
• ¿Se han probado en la práctica el plazo de conservación, el acceso, el registro de auditoría y la eliminación confirmada?
• ¿Trata el chatbot el texto extraído como no confiable y cita pasajes verificables?
• ¿Contienen las analíticas solo los eventos necesarios en lugar de nombres de archivos o contenidos?
• ¿Está probado el proceso de handoff con errores reales tanto en escritorio como en dispositivos móviles?

Conclusión: la subida segura comienza antes de enviar el archivo

Una buena función para subir documentos hace visibles los límites antes de que fluyan los datos. Después, separa la recepción técnica, el análisis de seguridad, la calidad del contenido y la decisión operativa. De este modo, un chatbot de IA puede utilizar los documentos como un contexto de conversación útil sin confiar precipitadamente en cada byte recibido o en cada instrucción extraída.

Si desea implementar un chatbot en su sitio web e integrar estos flujos en una arquitectura global y fiable, puede consultar las características de ChatReact. Planifique el proceso de subida como un servicio controlado, con un consentimiento transparente, un estado claro y un camino seguro hacia la atención humana.

Fuentes

• OWASP Cheat Sheet Series: File Upload
• MDN: accept HTML attribute
• W3C WAI: Understanding Status Messages
• W3C WAI: Understanding Error Identification
• EUR-Lex: Reglamento (UE) 2016/679