Cómo crear una política segura de carga de archivos para chats de atención al cliente
Un marco práctico de políticas para solicitar solo los archivos necesarios a los clientes, gestionar adjuntos inesperados y derivar los problemas de seguridad, privacidad y accesibilidad a las personas adecuadas.
Un botón de carga no es una política de carga de archivos
Las capturas de pantalla, facturas, fotografías y documentos pueden ayudar a resolver un caso, pero cada adjunto también genera una decisión operativa: qué se necesita, quién puede verlo, si es seguro abrirlo, cuánto tiempo se conserva y qué ocurre cuando el cliente envía algo inapropiado o arriesgado.
Una política de carga de archivos para atención al cliente convierte esas decisiones en instrucciones repetibles para clientes, operadores de primera línea, supervisores, responsables de privacidad y equipos de respuesta de seguridad. Debe aplicarse de forma coherente en los canales de conversación que utiliza tu equipo, reconociendo al mismo tiempo que el comportamiento de cada canal y su gestión interna pueden diferir.
Aplica una defensa en profundidad. OWASP aconseja que ninguna técnica de validación individual es suficiente para los archivos proporcionados por usuarios. Por tanto, una política sólida combina minimización de datos, categorías permitidas limitadas, controles técnicos que tu organización haya verificado, procedimientos para el personal, límites de acceso y reglas de escalado.
- Responsable de la política: nombra a la persona responsable de operaciones de soporte y a quienes aprueban desde privacidad, seguridad y gestión documental.
- Alcance: enumera todos los canales de soporte, colas, departamentos y tipos de caso cubiertos.
- Regla de decisión: solicita un archivo solo cuando sea necesario para resolver, verificar o investigar el caso indicado.
- Vía humana: ofrece a cada cliente una forma de continuar con una persona si no puede o no debe cargar un archivo.
Clasifica la tarea de soporte antes de solicitar un adjunto
El archivo más seguro es el que nunca recopilas. Antes de que un agente o flujo automatizado solicite una carga, clasifica la evidencia en uno de tres grupos: obligatoria, útil o prohibida.
La evidencia obligatoria es la información sin la cual el equipo no puede realizar razonablemente una acción de soporte concreta. La evidencia útil puede acelerar el diagnóstico, pero no es necesaria; ofrécela como opcional y explica la alternativa. La información prohibida no debe solicitarse ni aceptarse a través del chat de soporte habitual.
Este enfoque respalda la limitación de la finalidad y la minimización de datos. Cuando se aplica el RGPD, los datos personales deben recopilarse para una finalidad específica y limitarse a lo necesario para esa finalidad.
- Obligatoria: una captura recortada de un mensaje de error mostrado cuando el texto no pueda facilitarse de otra forma.
- Útil: una foto que muestre daños visibles durante el envío cuando el cliente pueda, en su lugar, describir el estado y proporcionar una referencia de pedido.
- No recopilar: contraseñas, códigos de un solo uso, códigos de verificación de tarjetas de pago, PIN, datos completos de la banda magnética, claves privadas o documentos de identidad no relacionados.
- Revisa cada solicitud recurrente de carga: ¿puede tomarse la misma decisión a partir de un número de pedido, número de caso, descripción textual o proceso seguro diseñado específicamente para ello?
Define las categorías permitidas y redacta las instrucciones para clientes antes de la carga
Define una lista breve de elementos permitidos para cada tipo de caso en lugar de permitir categorías amplias de archivos de forma predeterminada. OWASP recomienda admitir solo extensiones esenciales para la actividad y elegir los tipos menos dañinos y de menor riesgo que cubran la necesidad empresarial. Evita aceptar archivos comprimidos salvo que exista una razón documentada y tus responsables técnicos hayan aprobado un procesamiento seguro; la gestión de archivos comprimidos introduce riesgos relacionados con el tamaño descomprimido y la extracción.
Redacta la solicitud de carga en lenguaje claro antes de que actúe el cliente. La instrucción debe identificar la finalidad de soporte, el contenido mínimo necesario, los formatos aceptados y cualquier límite de tamaño relevante que se haya verificado para ese canal. También debe indicar qué eliminar y qué no enviar.
Las instrucciones accesibles no son opcionales. WCAG 2.2 exige etiquetas o instrucciones cuando se requiere una entrada del usuario, y los controles de carga necesitan un nombre de texto que describa su finalidad. No dependas únicamente del color, un icono o una imagen.
- Finalidad: «Para comprobar el problema de entrega, envía una foto del exterior del paquete y del artículo dañado».
- Mínimo: «Cubre tu dirección, número de teléfono, número de cuenta y cualquier información que no sea necesaria para mostrar el problema».
- Formato: indica solo formatos que tu equipo haya aprobado para esa tarea, como una captura de pantalla o fotografía cuando corresponda.
- Prohibición: «No envíes contraseñas, códigos de verificación, PIN de tarjetas, códigos de seguridad de tarjetas ni datos completos de tarjetas de pago».
- Alternativa: «Si no puedes cargar un archivo, describe el texto del error, la fecha y hora, y lo que intentabas hacer. Un agente puede ayudarte».
Gestiona los adjuntos inesperados y sensibles sin solicitar reenvíos
A veces, los clientes envían un archivo antes de que se les solicite, adjuntan el elemento equivocado o incluyen información sensible en una captura de pantalla. Los agentes no deben pedirles que reenvíen el mismo contenido sensible a través del mismo chat. La repetición amplía la exposición sin resolver el problema subyacente de gestión.
Crea un guion y una vía de contención sencillos. El agente debe confirmar el caso, detener la recopilación adicional de material sensible, documentar únicamente los hechos mínimos exigidos por el procedimiento interno y derivar el caso al equipo designado de privacidad, pagos, seguridad de cuentas o seguridad.
Los entornos de pago necesitan reglas especialmente claras. Los códigos de verificación de tarjetas, los PIN y los datos completos de la banda magnética son datos de autenticación sensibles y no son apropiados para adjuntos en chats de soporte habituales. Si llega información de pago, sigue el procedimiento aprobado por la organización para incidentes y eliminación de datos de pago, en lugar de copiarla en notas, plantillas u otro chat.
- Credencial o código de verificación enviado por accidente: indica al cliente que no envíe más información, recomiéndale cambiar o proteger la credencial a través de la vía aprobada para la cuenta y escala el caso a seguridad de cuentas.
- Datos de pago: interrumpe la conversación sobre los datos, no los repitas y escala el caso mediante el proceso aprobado de pagos o privacidad.
- Documento de identidad o información de categoría especial que no sea necesaria para el caso: confirma la recepción sin repetir detalles y escala el caso al responsable de privacidad.
- Archivo incorrecto o no relacionado: solicita una alternativa más segura o la información mínima relevante, no un reenvío del material original.
Proporciona a los operadores reglas seguras para abrir, describir y compartir archivos
El personal de soporte de primera línea no debe tomar por sí solo decisiones sobre malware o privacidad. NIST recomienda a los usuarios no abrir adjuntos sospechosos solo porque conozcan al remitente. Un nombre de cliente conocido, un tema de caso esperado o un nombre de archivo plausible no prueban que un archivo sea seguro.
Forma a los operadores para inspeccionar únicamente la información necesaria para el caso y solo mediante herramientas aprobadas. No deben descargar un archivo en un dispositivo personal, reenviarlo a un correo electrónico personal, cargarlo en un servicio no aprobado ni compartirlo en un grupo interno amplio simplemente para pedir ayuda.
Un valor Content-Type o MIME proporcionado por un cliente no es una prueba fiable del tipo real de un archivo. Los controles técnicos pueden utilizar listas de extensiones permitidas, firmas de archivo esperadas, límites de tamaño y análisis de malware o entornos aislados cuando estén disponibles, pero OWASP advierte que son salvaguardas complementarias, no garantías independientes.
- Abre normalmente un archivo solo cuando sea esperado, relevante para el caso activo, permitido por la política y accesible mediante procedimientos de gestión aprobados.
- Trátalo como sospechoso cuando el adjunto sea inesperado, irrelevante, parezca ejecutable, sea un archivo comprimido fuera de política, tenga un tamaño inusualmente grande, un nombre engañoso o vaya acompañado de presión para abrirlo con urgencia.
- Para archivos sospechosos: no los abras, previsualices, ejecutes ni investigues con herramientas de escritorio habituales; conserva la referencia del caso y escálalo a seguridad.
- Al describir un archivo internamente, registra los hechos mínimos útiles: ID del caso, hora de recepción, categoría aparente, motivo del escalado y acciones realizadas. No reproduzcas contenido sensible en las notas.
Verifica los límites entre canales, bandejas de entrada y tus propias salvaguardas
No redactes una política que dé por hecho que un canal de mensajería, un widget de chat o una bandeja de entrada proporciona análisis de malware, aplicación de tipos de archivo, controles de retención, flujos de eliminación o controles de acceso basados en roles, a menos que esas capacidades se hayan verificado explícitamente para la configuración exacta utilizada. El análisis y los entornos aislados son salvaguardas específicas de la implementación, no supuestos predeterminados.
webchat.vip proporciona una bandeja de entrada compartida para conversaciones de WebChat y WhatsApp. Los archivos se almacenan en una subcuenta aislada de Apification Cloud para cada servicio omnicanal. Estos hechos describen la arquitectura del producto, pero no establecen por sí mismos los controles de análisis, retención, revisión de accesos o respuesta ante incidentes que requiere tu organización.
Convierte la verificación técnica en un requisito formal de lanzamiento, responsabilidad de las partes interesadas adecuadas de seguridad, privacidad y plataforma. Registra la respuesta, las evidencias, la persona responsable, la fecha de revisión y cualquier riesgo residual para cada control.
- ¿Qué formatos de archivo, tamaños de archivo y tamaños de solicitud se aceptan realmente en cada canal desplegado?
- ¿Se analiza, pone en cuarentena o ejecuta en un entorno aislado un archivo? En caso afirmativo, ¿quién opera el control, cuál es su cobertura y qué ocurre ante una detección?
- ¿Quién puede ver, descargar, exportar, reenviar y eliminar adjuntos de clientes en la bandeja de entrada configurada y los sistemas conectados?
- ¿Dónde se almacenan los archivos, cómo se obtienen los registros de acceso y cómo funciona en la práctica el cumplimiento de la eliminación o retención?
- ¿Puede el equipo impedir nombres de archivo o rutas controlados por usuarios y están los archivos separados del contenido servido en la web cuando corresponde?
- ¿Qué proceso se aplica si un cliente solicita acceso, eliminación, rectificación o información sobre un archivo cargado?
Utiliza un escalado basado en riesgos, con una persona responsable designada
Toda política necesita una vía de escalado que funcione fuera del horario laboral y no dependa de que un agente adivine la gravedad. Define quién recibe el caso, cómo contactar con esa persona, qué hechos conservar y qué puede comunicar el agente de primera línea al cliente mientras se realiza la revisión.
Los posibles incidentes de privacidad requieren una evaluación rápida. Cuando se aplica el RGPD, los encargados del tratamiento deben notificar a los responsables sin dilación indebida después de tener conocimiento de una violación de datos personales, mientras que los responsables deben documentar los hechos pertinentes, los efectos y las medidas correctivas. Una notificación que cumpla los requisitos a una autoridad de control generalmente debe realizarse en un plazo de 72 horas desde que se tiene conocimiento, cuando sea posible, salvo que sea improbable que la violación genere un riesgo para los derechos y libertades de las personas.
La función del equipo de soporte es contener y transferir el caso con precisión, no realizar una clasificación jurídica. Las personas responsables de privacidad y seguridad deben evaluar el incidente conforme a las obligaciones aplicables y dirigir las comunicaciones.
- Adjunto sospechoso: derívalo inmediatamente al contacto de incidentes de seguridad; no lo abras con herramientas estándar.
- Posible toma de control de cuenta, exposición de credenciales o suplantación de identidad: deriva el caso a seguridad de cuentas y sigue el proceso aprobado de protección al cliente.
- Datos personales sensibles enviados por accidente o archivo dirigido erróneamente: deriva el caso a la persona responsable de privacidad o al contacto de protección de datos.
- Requerimiento legal, solicitud de preservación o contacto de autoridades policiales: deriva el caso a los responsables legales y de gestión documental; los agentes no deben prometer la eliminación ni divulgar archivos por su cuenta.
- Mensaje inmediato al cliente: confirma que el archivo se revisará mediante el proceso adecuado, pídele que no envíe más información sensible y ofrécele una vía de contacto con una persona.
Establece expectativas de retención, eliminación, acceso y auditoría
Los adjuntos no deben conservarse indefinidamente solo porque resultan convenientes. Establece un calendario de retención por tipo de caso y finalidad, y después define el evento que inicia el plazo, el método aprobado de eliminación o disposición, las excepciones como las retenciones legales y quién autoriza dichas excepciones.
El principio de limitación del plazo de conservación del RGPD exige que los datos personales identificables se conserven no más tiempo del necesario para su finalidad. La orientación de PCI exige de manera similar políticas de retención y eliminación que limiten el almacenamiento a necesidades legales, regulatorias o empresariales y eliminen de forma segura o hagan irrecuperables los datos que ya no se necesitan.
El acceso debe responder a la tarea de soporte, no a la curiosidad general. Limita el acceso a archivos a las personas que actúan conforme a instrucciones organizativas documentadas, revisa el acceso periódicamente y conserva suficiente información de auditoría para investigar una gestión inapropiada y demostrar que se siguió la política.
- Mantén un calendario de retención para cada categoría de adjunto, incluidos los plazos de eliminación rutinaria y la persona responsable de las excepciones.
- Documenta cómo se solicita, realiza y confirma la eliminación en la bandeja de entrada, el almacenamiento y cualquier sistema posterior aprobado.
- Aplica el acceso mínimo necesario por departamento y función; elimina el acceso cuando cambien las responsabilidades.
- Registra los eventos significativos de adjuntos: carga, transferencia interna cuando corresponda, escalado, solicitud de eliminación, acción de eliminación y excepción a la política.
- Realiza revisiones periódicas de la eficacia de las salvaguardas técnicas y organizativas, según lo exija tu programa de gobernanza.
Preguntas frecuentes
¿Qué debe incluir una política de carga de archivos para atención al cliente?
Incluye las finalidades de soporte que justifican las cargas, categorías de archivos permitidas y prohibidas, instrucciones para clientes, comportamiento seguro de los operadores, verificación de controles técnicos, contactos de escalado, reglas de retención y eliminación, alternativas de accesibilidad, formación, pruebas y métricas.
¿Deben los equipos de soporte aceptar documentos de identidad en el chat?
Solo si un proceso de verificación específico y aprobado los requiere realmente. El chat de soporte habitual no debe recopilar documentos de identidad de forma predeterminada. Proporciona una alternativa diseñada específicamente para ese fin o una vía de escalado a una persona cuando sea necesaria la verificación de identidad.
¿Pueden los agentes confiar en una extensión de archivo o en un valor Content-Type?
No. Un valor Content-Type proporcionado por un usuario puede falsificarse, y una extensión por sí sola no prueba que un archivo sea seguro. Los equipos técnicos deben usar controles complementarios y los operadores deben escalar los archivos sospechosos en lugar de abrirlos.
¿Qué debe hacer un agente si un cliente envía una contraseña o un código de seguridad de tarjeta?
No repitas, copies ni solicites de nuevo la información. Detén la recopilación adicional, sigue el guion de contención aprobado y escala el caso a la persona responsable de seguridad de cuentas, pagos o privacidad, según corresponda. Ofrece al cliente una vía más segura para proteger su cuenta o completar la tarea.
¿webchat.vip proporciona automáticamente análisis de malware o controles de retención para adjuntos?
No lo des por hecho. webchat.vip proporciona una bandeja de entrada compartida para conversaciones de WebChat y WhatsApp, y los archivos se almacenan en una subcuenta aislada de Apification Cloud para cada servicio omnicanal. Tu equipo debe verificar el comportamiento de análisis, retención, acceso, exportación y eliminación en la configuración desplegada antes de confiar en cualquier control.
¿Cómo puede la automatización solicitar archivos de forma segura?
Utiliza la automatización solo para solicitudes definidas de forma limitada y revisadas por personas. Indica la finalidad y el contenido mínimo necesario, recopila respuestas validadas cuando corresponda, crea ramificaciones hacia alternativas de texto más seguras y proporciona siempre una transferencia o derivación a una persona. No automatices una solicitud de material sensible que el proceso posterior no pueda gestionar de forma segura.
Fuentes y lecturas adicionales
Referencias primarias y autorizadas usadas para verificar la base factual de esta guía.
- File Upload Cheat Sheet — OWASP Foundation
- Input Validation Cheat Sheet — OWASP Foundation
- Web Content Accessibility Guidelines (WCAG) 2.2 — W3C
- Forms Tutorial — W3C Web Accessibility Initiative
- Regulation (EU) 2016/679 (GDPR) — EUR-Lex / European Union
- NIST Privacy Framework 1.1: Using the Framework — National Institute of Standards and Technology
- Security and Privacy Controls for Information Systems and Organizations — National Institute of Standards and Technology
- Computer Security Incident Handling Guide — National Institute of Standards and Technology
- Can card verification codes be stored for card-on-file or recurring transactions? — PCI Security Standards Council
- What is the maximum period of time that cardholder data can be stored? — PCI Security Standards Council