Cómo desplegar firma biométrica con Wacom en cientos de sucursales bancarias
Guía para desplegar firma biométrica con tabletas Wacom en una red bancaria: arquitectura, instalación, actualizaciones, soporte, monitorización y escalabilidad
Cómo desplegar firma biométrica con Wacom en cientos de sucursales bancarias
Implantar firma biométrica en una oficina bancaria es relativamente sencillo.
El verdadero reto comienza cuando la misma solución debe funcionar de forma homogénea en cientos o miles de puestos distribuidos por toda una red de sucursales.
En ese momento, la pregunta deja de ser únicamente si una tableta Wacom puede capturar correctamente una firma.
Aparecen otras cuestiones mucho más importantes.
¿Cómo se instala el software en todos los puestos?
¿Cómo se identifica cada dispositivo?
¿Cómo se distribuyen las actualizaciones?
¿Qué ocurre cuando cambia el navegador o el sistema operativo?
¿Cómo se sustituye una tableta averiada?
¿Qué pasa si el servicio de firma no está disponible?
¿Cómo se monitorizan las incidencias?
¿Y cómo podemos garantizar que una aplicación que funciona hoy seguirá funcionando dentro de varios años?
Por eso un proyecto de firma biométrica a gran escala en banca debe diseñarse desde el principio pensando en operación, mantenimiento y escalabilidad.
edatalia cuenta con experiencia en proyectos de firma digital manuscrita para entidades financieras de España y Latinoamérica y trabaja con dispositivos profesionales Wacom para integrar la captura de firma directamente en las aplicaciones corporativas.
Puedes conocer el contexto general de estos proyectos en:
edatalia, referente en firma digital manuscrita para banca en España y Latinoamérica
Una prueba piloto no es un despliegue corporativo
Una prueba de concepto suele realizarse en condiciones controladas.
Uno o varios dispositivos.
Un pequeño número de usuarios.
Un equipo técnico disponible para resolver cualquier problema.
Y una única versión de sistema operativo y aplicación.
En estas condiciones es relativamente fácil conseguir que todo funcione correctamente.
Pero una red bancaria presenta una realidad diferente.
Puede haber cientos de oficinas.
Miles de empleados.
Versiones diferentes de Windows.
Políticas corporativas de seguridad.
Infraestructuras virtualizadas.
Conexiones de distinta calidad.
Puestos bloqueados mediante herramientas de administración.
Aplicaciones que evolucionan continuamente.
Y dispositivos instalados durante muchos años.
Por eso una solución diseñada únicamente para superar una demo puede encontrarse con problemas cuando llega el despliegue real.
La arquitectura debe pensarse desde el principio para funcionar a escala.
El primer paso: analizar la red de sucursales
Antes de seleccionar dispositivos o instalar software es necesario conocer el entorno real.
¿Cuántas oficinas existen?
¿Cuántos puestos necesitan firma?
¿Todos los puestos realizan las mismas operaciones?
¿Existe un único modelo de ordenador?
¿Qué sistemas operativos están soportados?
¿Qué aplicaciones utilizan los empleados?
¿Son aplicaciones web o de escritorio?
¿Existe VDI, Citrix o escritorio remoto?
¿Cómo se distribuye actualmente el software?
¿Qué herramientas utiliza el banco para monitorizar los equipos?
Responder estas preguntas permite dimensionar correctamente el proyecto.
Una red de 50 puestos no tiene las mismas necesidades que una infraestructura de 3.000 terminales.
No todos los puestos necesitan necesariamente una tableta
Uno de los primeros ejercicios consiste en determinar dónde es realmente necesaria la firma.
Puede que una oficina disponga de diez empleados, pero solo cuatro puestos formalicen contratos con clientes.
También puede existir una zona específica de contratación.
O puede ser necesario compartir determinados dispositivos.
La decisión depende del modelo operativo.
Instalar automáticamente una tableta en cada ordenador puede incrementar innecesariamente el coste de hardware, instalación y soporte.
El diseño debería partir del proceso y del volumen de operaciones.
Elegir correctamente entre Wacom STU y DTU
La elección del dispositivo influye directamente en el despliegue.
Las tabletas de la familia Wacom STU ofrecen un formato compacto especialmente adecuado cuando el objetivo principal es recoger la firma manuscrita.
Las pantallas de la familia Wacom DTU proporcionan una superficie mayor y pueden utilizarse cuando el cliente necesita visualizar una mayor cantidad de información o interactuar con el documento.
La elección no debería basarse únicamente en el precio.
Debe analizarse la experiencia que necesita el cliente.
Lo explicamos con más detalle en:
Tabletas Wacom para bancos: diferencias entre STU y DTU y cuál elegir
Una gran entidad puede incluso utilizar diferentes familias de dispositivos según el tipo de oficina o proceso.
La estandarización reduce enormemente el coste de soporte
Cuanto mayor sea el despliegue, más importante resulta limitar la diversidad tecnológica.
Si existen demasiados modelos de dispositivos, versiones de software o configuraciones diferentes, el soporte se vuelve progresivamente más complejo.
Siempre que sea posible, conviene definir configuraciones estándar.
Por ejemplo:
- modelo de tableta aprobado;
- versión de componente de firma;
- sistema operativo soportado;
- configuración USB;
- navegador corporativo;
- política de actualización.
Esto no significa impedir cualquier evolución.
Significa controlar la diversidad.
En una red de miles de dispositivos, pequeñas diferencias pueden multiplicarse rápidamente en forma de incidencias.
La importancia de identificar cada dispositivo
En un despliegue empresarial resulta conveniente poder identificar los dispositivos instalados.
El sistema puede asociar una tableta a un puesto, una oficina o una determinada configuración.
Esto facilita tanto la operación como el soporte.
Si aparece una incidencia, el equipo técnico puede saber qué dispositivo intervino.
Si un modelo necesita actualizarse o sustituirse, puede localizarse.
Y si se introduce un nuevo hardware, puede controlarse progresivamente su despliegue.
La gestión del dispositivo debería formar parte de la arquitectura y no depender exclusivamente de inventarios manuales.
Inventario de tabletas de firma
Una entidad puede tratar las tabletas Wacom como cualquier otro activo tecnológico corporativo.
Cada dispositivo puede disponer de información como:
- identificador;
- modelo;
- número de serie;
- oficina;
- puesto;
- fecha de instalación;
- versión del software asociado;
- estado;
- fecha de última incidencia.
Este inventario ayuda a gestionar el ciclo de vida completo.
Desde la instalación inicial hasta la sustitución.
En una red de varios miles de dispositivos, disponer de esta información deja de ser opcional.
Integración con herramientas de distribución corporativa
La instalación manual puede ser aceptable en un piloto.
No lo es en un despliegue de miles de puestos.
Los componentes necesarios deberían poder distribuirse utilizando las herramientas corporativas que ya utiliza el banco.
El objetivo es automatizar:
instalación,
configuración,
actualización,
desinstalación
y, cuando sea posible, diagnóstico.
Cuanto menor sea la intervención presencial de un técnico, menor será el coste operativo del proyecto.
Integración web o cliente-servidor
La arquitectura de la aplicación bancaria condiciona también la estrategia de despliegue.
En aplicaciones tradicionales puede existir un componente cliente que se comunica directamente con el dispositivo.
En aplicaciones web es necesario resolver la comunicación entre el navegador y la tableta de una forma compatible con los estándares y políticas modernas.
WebSign está orientado precisamente a incorporar firma manuscrita con dispositivos Wacom en aplicaciones web.
Esto permite que la funcionalidad de firma se integre en el propio flujo de la aplicación bancaria.
El empleado no necesita abrir un programa diferente.
Evitar Java y tecnologías heredadas
Durante años, muchas aplicaciones empresariales utilizaron applets Java o plugins propietarios para comunicarse con dispositivos periféricos.
Este modelo ha quedado obsoleto en los navegadores modernos.
En una red bancaria, mantener dependencias de este tipo puede generar importantes problemas de seguridad y compatibilidad.
Una arquitectura moderna debería minimizar este tipo de componentes y utilizar mecanismos compatibles con navegadores actuales.
Esto reduce el riesgo de que una actualización del navegador deje inutilizada la firma de toda una red.
Separar la aplicación bancaria del hardware
Uno de los principios arquitectónicos más importantes consiste en evitar que cada aplicación tenga que conocer los detalles técnicos de una Wacom concreta.
La aplicación bancaria debería solicitar:
"Necesito firmar este documento."
No debería tener que gestionar directamente cada comando del dispositivo.
Una capa especializada puede encargarse de la comunicación con el hardware.
Esto reduce el acoplamiento.
También facilita cambiar de modelo dentro de una misma familia o introducir nuevos dispositivos en el futuro.
La aplicación de negocio permanece estable.
La capa de firma evoluciona de forma independiente.
Una API común para diferentes aplicaciones
Los bancos suelen disponer de múltiples aplicaciones.
Contratación.
Préstamos.
Inversión.
Atención al cliente.
Operaciones de caja.
Aplicaciones internas.
Cada una podría necesitar firma.
Crear una integración diferente para cada aplicación genera duplicidades.
Una arquitectura centralizada puede proporcionar una API o servicio común de firma reutilizable por diferentes sistemas.
De esta manera, la entidad mantiene una única política de captura, evidencias y seguridad.
Y las aplicaciones solamente necesitan integrar el servicio correspondiente.
Arquitectura centralizada frente a lógica en cada puesto
Un proyecto de gran escala debe decidir qué funciones se ejecutan localmente y cuáles se gestionan de forma centralizada.
Normalmente el componente que se comunica físicamente con la tableta necesita algún elemento próximo al puesto.
Pero otras funciones pueden centralizarse.
Procesamiento documental.
Configuraciones.
Políticas.
Auditoría.
Gestión de certificados.
Monitorización.
La arquitectura debe buscar un equilibrio entre rendimiento, disponibilidad, seguridad y facilidad de mantenimiento.
On-premise, cloud o arquitectura híbrida
Las entidades financieras pueden tener requisitos muy diferentes.
Algunas necesitan mantener determinados componentes dentro de su infraestructura.
Otras están adoptando servicios cloud.
Y muchas utilizan modelos híbridos.
La solución de firma debe poder adaptarse al entorno corporativo.
No debería obligar a transformar toda la infraestructura únicamente para incorporar una tableta.
La documentación oficial de Wacom sobre la integración con edatalia describe diferentes posibilidades de arquitectura y despliegue.
Wacom for Business: información sobre la integración de edatalia con dispositivos STU y DTU
Diseñar pensando en miles de transacciones
La escalabilidad no se refiere únicamente al número de dispositivos.
También importa el volumen de operaciones.
Una entidad puede generar miles o millones de documentos firmados.
La arquitectura debe soportar picos de actividad.
Por ejemplo, campañas comerciales, cierres de operaciones o determinados horarios pueden concentrar un gran número de firmas.
Los servicios centrales deben dimensionarse teniendo en cuenta estos escenarios.
No únicamente el consumo medio.
El documento no debería viajar innecesariamente
La arquitectura debe analizar también cómo circula la documentación.
En determinados proyectos puede resultar conveniente que el PDF permanezca dentro de la infraestructura de la entidad.
En otros, determinados servicios pueden procesarlo externamente.
La decisión depende de requisitos de seguridad, privacidad, rendimiento y arquitectura.
Lo importante es definir claramente dónde se encuentra el documento en cada momento.
Y evitar transferencias innecesarias.
Firma y biometría deben permanecer vinculadas
Aunque este artículo está centrado en despliegue, la escala no debe hacer perder de vista la evidencia jurídica.
Cada uno de los miles o millones de documentos firmados debe mantener las mismas garantías.
Los datos biométricos deben estar correctamente relacionados con el documento.
La integridad debe protegerse.
Las evidencias deben conservarse.
Un sistema que escala técnicamente pero pierde garantías probatorias no cumple el objetivo.
Cifrado de datos biométricos
Los datos dinámicos de la firma deben protegerse con medidas adecuadas.
En las soluciones de edatalia pueden mantenerse cifrados y vinculados al documento.
Esto evita que la gestión ordinaria del PDF requiera acceder a la biometría.
La protección debe funcionar de igual manera en el dispositivo número 1 y en el número 5.000.
La seguridad no puede depender de configuraciones manuales distintas en cada oficina.
Gestión centralizada de certificados
Los certificados utilizados para proteger o sellar documentos deberían gestionarse de manera controlada.
No resulta adecuado instalar manualmente credenciales sensibles sin una política corporativa.
La entidad debe decidir:
qué certificado se utiliza,
dónde se almacena,
qué servicios pueden usarlo,
cómo se renueva,
qué ocurre cuando expira
y cómo se protege la clave privada.
Estas decisiones deben incorporarse al diseño de infraestructura.
Sellado de tiempo
Determinados procesos pueden incorporar sellado de tiempo para reforzar las evidencias temporales.
Cuando se utiliza este mecanismo a gran escala, también debe analizarse su capacidad.
Número de solicitudes.
Disponibilidad.
Latencia.
Contingencia.
La firma del cliente no debería quedarse bloqueada durante largos periodos porque un servicio externo no responde.
El diseño tiene que definir cómo actuar ante incidencias.
Alta disponibilidad
Una vez que una entidad elimina el papel, la plataforma de firma puede convertirse en infraestructura crítica.
Antes siempre existía una alternativa sencilla:
imprimir.
Después de digitalizar completamente el proceso, una indisponibilidad puede impedir formalizar determinadas operaciones.
Por eso debe analizarse la alta disponibilidad.
Servicios redundantes.
Balanceo.
Recuperación.
Backups.
Monitorización.
Contingencia.
El nivel necesario dependerá de la criticidad del proceso.
Diseñar un plan de contingencia
Todo sistema puede fallar.
La pregunta importante es qué ocurre cuando lo hace.
¿Puede continuar la operación?
¿Se puede reintentar la firma?
¿Qué ocurre si falla únicamente una tableta?
¿Y si falla un servicio central?
¿Existe un mecanismo alternativo de firma?
¿Puede utilizarse firma remota como contingencia?
Estas decisiones deben tomarse antes del despliegue.
No cuando la red completa ya está en producción.
Una incidencia local no debería detener toda la oficina
Si una tableta deja de funcionar, la arquitectura debe limitar el impacto.
Puede existir otro puesto disponible.
Puede sustituirse el dispositivo.
O puede utilizarse temporalmente otro canal.
La aplicación debería gestionar los errores de manera comprensible.
Un fallo de hardware no debería dejar bloqueada toda la sesión del empleado ni exigir reiniciar aplicaciones innecesariamente.
Sustitución de dispositivos
En una red grande existirán averías.
Aunque la tasa de fallos sea muy reducida, el volumen total hace inevitable que algunos dispositivos tengan que sustituirse.
El procedimiento debería ser sencillo.
Retirar la tableta.
Conectar la nueva.
Asociarla al puesto si es necesario.
Comprobar funcionamiento.
Continuar trabajando.
Cuantos más pasos manuales y configuraciones específicas requiera la sustitución, mayor será el coste de soporte.
Stock de contingencia
Una organización con una red extensa puede mantener un pequeño stock de dispositivos para sustituciones.
El número adecuado dependerá del tamaño del parque y de los acuerdos de soporte.
Esto permite reducir tiempos de indisponibilidad.
También conviene disponer de un procedimiento para diagnosticar si la incidencia procede realmente de la tableta, del software, del puerto USB o de la aplicación.
No todos los problemas atribuidos inicialmente al dispositivo tienen su origen en el hardware.
La importancia de un lápiz sin batería
Los dispositivos profesionales Wacom utilizan lápices que no requieren batería.
En una única oficina puede parecer un detalle menor.
En miles de puestos supone eliminar una fuente potencial de mantenimiento.
No es necesario cargar los lápices.
No existen baterías degradadas.
No se requiere gestionar cargadores.
El dispositivo está disponible cuando llega el cliente.
Las pequeñas ventajas operativas adquieren gran importancia cuando se multiplican por una red completa.
Cableado y ergonomía
El diseño físico del puesto también debe analizarse.
Dónde se coloca la tableta.
Cómo llega el cable.
Si el cliente puede alcanzar cómodamente el dispositivo.
Cómo se evita que el hardware se mueva.
Si necesita anclaje.
Si interfiere con otros periféricos.
Una mala ergonomía puede generar una experiencia deficiente aunque el software funcione perfectamente.
Por eso el piloto debería realizarse en oficinas reales y no únicamente en un laboratorio.
Virtualización, Citrix y escritorios remotos
Muchas entidades utilizan infraestructuras virtualizadas.
Esto introduce desafíos adicionales cuando existe hardware conectado físicamente al puesto.
La arquitectura debe analizar cómo se detecta el dispositivo desde la sesión del usuario y qué componentes necesitan ejecutarse localmente.
Entornos como Citrix, VDI o escritorios remotos deberían probarse específicamente.
No conviene asumir que una integración que funciona en un PC convencional se comportará exactamente igual en un entorno virtual.
Compatibilidad con Windows y otras plataformas
El sistema operativo forma parte de la matriz de compatibilidad.
Una entidad debe saber qué versiones están soportadas hoy y cómo se gestionarán futuras migraciones.
Por ejemplo, un banco puede comenzar un proyecto con una versión concreta de Windows y migrar toda su red varios años después.
La capa de firma debería evolucionar sin obligar a modificar todas las aplicaciones de negocio.
De nuevo, el desacoplamiento reduce el impacto.
Los navegadores también cambian
En aplicaciones web existe otra dependencia: el navegador.
Chrome, Edge y otros navegadores se actualizan con frecuencia.
Modifican políticas.
Eliminan funcionalidades.
Refuerzan restricciones de seguridad.
Un componente de firma web debe estar preparado para evolucionar en ese entorno.
El banco debería disponer de una matriz de versiones soportadas y de un procedimiento para validar nuevas releases antes de su despliegue corporativo.
Entornos de desarrollo, integración y preproducción
Los cambios no deberían probarse directamente en producción.
Una infraestructura empresarial necesita entornos controlados.
Desarrollo.
Integración.
Preproducción.
Producción.
Cuando aparece una nueva versión del componente de firma, puede probarse primero en laboratorio.
Después con las aplicaciones integradas.
Posteriormente en un conjunto reducido de puestos.
Y finalmente desplegarse al resto de la red.
Este enfoque disminuye significativamente el riesgo.
Actualizaciones progresivas
En redes muy grandes puede ser conveniente evitar actualizaciones simultáneas.
Un despliegue por fases permite detectar incidencias antes de afectar a toda la organización.
Por ejemplo:
- laboratorio;
- usuarios internos;
- diez oficinas piloto;
- cien oficinas;
- resto de la red.
Si aparece un problema, puede detenerse la distribución.
Este mecanismo es especialmente importante cuando el componente interactúa con hardware.
Control de versiones
La organización debería conocer qué versión utiliza cada puesto.
Sin esta información resulta difícil diagnosticar incidencias.
Un sistema de inventario puede indicar:
dispositivo,
versión del componente,
versión de firmware si aplica,
sistema operativo,
navegador
y aplicación.
Cuando llega un ticket, soporte dispone inmediatamente del contexto técnico.
Compatibilidad hacia atrás
Durante una actualización pueden coexistir temporalmente diferentes versiones.
Por eso resulta conveniente analizar qué compatibilidades existen.
¿La nueva aplicación bancaria funciona con el componente anterior?
¿El nuevo componente funciona con documentos generados por versiones anteriores?
¿Puede el servidor aceptar diferentes clientes durante una migración?
Diseñar esta transición evita obligar a realizar cambios simultáneos en toda la organización.
Monitorización del servicio
Una infraestructura crítica necesita monitorización.
No debería ser necesario esperar a que una sucursal llame para saber que existe un problema general.
Los servicios centrales pueden generar métricas sobre disponibilidad, tiempos de respuesta y errores.
También puede analizarse el volumen de operaciones.
Si la tasa de fallos aumenta repentinamente después de una actualización, el equipo puede detectarlo rápidamente.
¿Qué conviene monitorizar?
Algunos indicadores pueden ser:
- operaciones iniciadas;
- firmas completadas;
- errores;
- tiempo medio;
- disponibilidad de servicios;
- dispositivos con incidencias;
- versión instalada;
- fallos de comunicación;
- errores de generación documental.
La monitorización debe respetar, por supuesto, los principios de seguridad y protección de datos.
No es necesario almacenar contenido contractual para conocer si un servicio funciona correctamente.
Logs centralizados
Los registros técnicos son especialmente útiles en sistemas distribuidos.
Si cada puesto almacena sus propios logs sin una estrategia central, diagnosticar un problema puede resultar complejo.
Los registros necesarios pueden centralizarse o recogerse mediante herramientas corporativas.
De esta manera, los equipos de soporte pueden buscar patrones.
Por ejemplo, comprobar si un determinado error afecta únicamente a una versión concreta de Windows.
Soporte de primer, segundo y tercer nivel
En grandes despliegues conviene definir responsabilidades.
El primer nivel puede atender incidencias básicas.
Comprobar conexión.
Reiniciar componente.
Validar que el dispositivo está disponible.
El segundo nivel puede analizar configuraciones y logs.
El tercer nivel puede involucrar al fabricante o proveedor especializado cuando existe un problema técnico profundo.
Esta estructura evita escalar innecesariamente incidencias sencillas.
Documentación para soporte
El equipo de soporte debería disponer de procedimientos claros.
¿Cómo comprobar que Windows detecta la tableta?
¿Cómo validar el servicio local?
¿Cómo probar una firma?
¿Qué logs deben recogerse?
¿Cómo sustituir el dispositivo?
¿Qué información debe incluir un ticket?
Una buena documentación puede reducir enormemente el tiempo medio de resolución.
El piloto debe probar también el soporte
Un piloto no debería evaluar únicamente la experiencia del cliente.
También debe comprobar qué ocurre cuando algo falla.
Desconectar la tableta.
Cambiarla de puerto.
Reiniciar el equipo.
Simular pérdida de conectividad.
Actualizar el navegador.
Sustituir el dispositivo.
Estas pruebas proporcionan información muy valiosa antes del despliegue masivo.
Cómo diseñar un buen piloto bancario
Un piloto representativo debería incluir diferentes tipos de oficina y usuarios.
No únicamente la sede central.
Conviene probar en:
oficinas pequeñas,
sucursales de alto volumen,
puestos con distintas configuraciones,
usuarios con diferentes perfiles
y conexiones representativas.
El objetivo es descubrir las excepciones antes de desplegar.
Qué medir durante el piloto
Además de comprobar que la firma funciona, pueden medirse:
tiempo de operación,
porcentaje de firmas completadas,
incidencias,
tiempo de recuperación,
satisfacción del empleado,
experiencia del cliente,
uso de papel antes y después,
tiempo de archivo,
errores documentales.
Estos datos ayudan a justificar posteriormente el despliegue.
Formación de los empleados
La tecnología debe ser suficientemente sencilla para requerir poca formación.
Pero el empleado necesita entender el flujo.
Cuándo solicitar la firma.
Qué verá el cliente.
Qué hacer si cancela.
Qué hacer si la firma no se captura correctamente.
Qué ocurre con el documento final.
La formación debe centrarse más en el proceso que en la tecnología.
La experiencia del cliente
El cliente no debería percibir la complejidad de toda esta infraestructura.
Para él, el proceso debería ser sencillo:
revisar,
firmar
y continuar.
La tecnología funciona detrás.
Una buena integración consigue precisamente eso: ocultar la complejidad técnica sin reducir las garantías del proceso.
Integración con el gestor documental
Después de la firma, el documento debe almacenarse automáticamente.
No tiene sentido digitalizar la captura y mantener después un proceso manual de archivo.
El sistema puede enviar el PDF al gestor documental con los metadatos correspondientes.
Cliente.
Operación.
Tipo documental.
Fecha.
Identificador.
De esta manera el empleado no necesita realizar ninguna acción adicional.
Integración con el core bancario
El core o las aplicaciones de negocio deben conocer el resultado.
La operación puede avanzar cuando la firma se completa.
Puede cambiar de estado.
Puede generar nuevos procesos.
Puede enviar una copia al cliente.
La firma no es un proceso independiente.
Forma parte del ciclo de negocio.
Integración con CRM
En procesos comerciales, el documento puede también relacionarse con la ficha del cliente.
Esto proporciona una visión completa al gestor.
La automatización evita subir manualmente documentos y reduce errores de clasificación.
Firma biométrica y estrategia omnicanal
Una red de sucursales no es el único canal del banco.
Los mismos clientes utilizan web y móvil.
Por eso el sistema debería poder convivir con mecanismos de firma remota.
En oficina:
firma biométrica.
A distancia:
firma remota.
La aplicación puede seleccionar el mecanismo adecuado según el contexto.
Este enfoque permite construir una verdadera estrategia omnicanal.
La firma remota como mecanismo de contingencia
En determinados escenarios, disponer de un canal remoto puede proporcionar además una alternativa.
Si el cliente no puede completar presencialmente la operación, puede continuarse posteriormente.
Esto no significa necesariamente que la firma remota deba utilizarse como contingencia técnica automática.
Cada proceso debe cumplir sus requisitos.
Pero disponer de diferentes canales aumenta la flexibilidad del modelo operativo.
Seguridad de los componentes locales
Cualquier software instalado en miles de puestos debe analizarse desde el punto de vista de seguridad.
Permisos.
Puertos.
Comunicación.
Actualizaciones.
Firma del software.
Control de acceso.
El principio debería ser utilizar únicamente los privilegios necesarios.
Una solución que requiere permisos excesivos aumenta la superficie de riesgo.
Comunicaciones cifradas
Las comunicaciones entre componentes deberían protegerse.
Especialmente cuando incluyen documentos o información relacionada con la firma.
El diseño debe analizar cada conexión.
Puesto a servicio local.
Servicio local a backend.
Backend a servicios externos.
Las políticas de seguridad del banco deben aplicarse al conjunto.
Gestión de secretos
Claves API, certificados y otros secretos no deberían almacenarse de manera insegura en cada puesto.
Siempre que sea posible, deben utilizarse mecanismos de gestión centralizada.
La rotación debe estar prevista.
Y la aplicación no debería depender de credenciales incrustadas de forma estática.
Auditoría del despliegue
Una entidad debería ser capaz de saber qué versión se encuentra instalada y cuándo se realizó una actualización.
También quién autorizó un determinado cambio.
Esta trazabilidad facilita auditorías y análisis de incidentes.
La gestión de configuración forma parte de la seguridad.
Planificar el ciclo de vida completo
Un dispositivo instalado hoy puede permanecer años en una oficina.
Por eso el proyecto debe contemplar su ciclo de vida.
Compra.
Instalación.
Uso.
Actualización.
Soporte.
Sustitución.
Retirada.
Lo mismo ocurre con el software.
Pensar únicamente en el día de la implantación genera deuda operativa futura.
Capacidad de evolución
Es probable que las necesidades cambien.
Nuevos productos.
Nuevas aplicaciones.
Nuevos dispositivos.
Nuevos sistemas operativos.
Nuevos canales.
Una arquitectura flexible permite incorporar estos cambios sin reconstruir el sistema.
De nuevo, separar aplicación, capa de firma y dispositivo resulta fundamental.
Experiencia de Wacom y edatalia en entornos empresariales
Wacom dispone de dispositivos profesionales diseñados para captura de firma en entornos empresariales.
edatalia integra esta tecnología dentro de soluciones de firma manuscrita y biométrica.
La propia Wacom dispone de documentación específica sobre la integración con edatalia y las familias STU y DTU:
Información oficial de Wacom sobre la integración de edatalia con dispositivos STU y DTU
También puedes consultar:
Wacom + edatalia: soluciones profesionales de firma digital manuscrita
Experiencia de edatalia en banca
edatalia cuenta con referencias en entidades financieras de España y Latinoamérica.
La experiencia en este sector resulta especialmente importante porque permite abordar no solo la captura, sino también integración, escalabilidad, soporte y evidencias.
Puedes consultar el artículo principal de este cluster:
edatalia, referente en firma digital manuscrita para banca en España y Latinoamérica
Y para comprender el objetivo operativo del despliegue:
Firma biométrica en banca: cómo eliminar el papel en las sucursales
Fases recomendadas para un despliegue masivo
Un proyecto de gran escala puede estructurarse en varias fases.
1. Análisis
Procesos, aplicaciones, puestos, infraestructura y volumen.
2. Arquitectura
Definición de componentes, comunicaciones, seguridad y evidencias.
3. Integración
Incorporación de la firma a las aplicaciones.
4. Laboratorio
Pruebas técnicas y funcionales.
5. Piloto
Despliegue limitado en oficinas representativas.
6. Evaluación
Análisis de métricas, incidencias y experiencia.
7. Despliegue progresivo
Extensión por oleadas.
8. Operación
Monitorización, soporte y mantenimiento.
9. Evolución
Actualizaciones, nuevas aplicaciones y nuevos dispositivos.
Este enfoque reduce considerablemente el riesgo frente a un despliegue simultáneo en toda la organización.
Checklist antes de desplegar en cientos de sucursales
Antes del despliegue, la entidad debería tener respuesta clara a estas preguntas:
- ¿Qué procesos van a utilizar firma biométrica?
- ¿Cuántos puestos requieren dispositivo?
- ¿Qué modelo Wacom se utilizará?
- ¿Cómo se identifica cada dispositivo?
- ¿Cómo se instala el software?
- ¿Cómo se distribuyen actualizaciones?
- ¿Qué sistemas operativos están soportados?
- ¿Qué navegadores están soportados?
- ¿Existen entornos Citrix o VDI?
- ¿Cómo se integra con las aplicaciones?
- ¿Dónde se procesa el PDF?
- ¿Cómo se protege la biometría?
- ¿Qué certificados se utilizan?
- ¿Cómo se gestionan las claves?
- ¿Qué ocurre si falla un servicio?
- ¿Existe alta disponibilidad?
- ¿Qué métricas se monitorizan?
- ¿Cómo se recogen logs?
- ¿Cómo se sustituye una tableta?
- ¿Existe stock de contingencia?
- ¿Quién presta soporte de primer nivel?
- ¿Quién presta soporte especializado?
- ¿Cómo se valida una nueva versión?
- ¿Cómo se despliegan actualizaciones progresivamente?
- ¿Cómo se conserva el documento final?
- ¿Qué evidencias se guardan?
- ¿Cómo se audita el sistema?
- ¿Qué mecanismo alternativo existe ante una incidencia?
- ¿Cómo se forma a los empleados?
- ¿Cómo se medirá el éxito del proyecto?
Si muchas de estas preguntas no tienen respuesta, probablemente el proyecto todavía se encuentre en fase de prueba y no esté preparado para un despliegue enterprise.
Preguntas frecuentes sobre despliegues Wacom en banca
¿Se pueden instalar tabletas Wacom en cientos de sucursales?
Sí. El reto no está únicamente en el hardware, sino en diseñar adecuadamente la distribución, integración, configuración, soporte y mantenimiento.
¿Es necesario instalar software en cada puesto?
Depende de la arquitectura. Puede ser necesario disponer de componentes locales para comunicarse con el dispositivo, mientras que otras funciones pueden centralizarse.
¿Se puede integrar la firma en aplicaciones web?
Sí. Soluciones como WebSign están orientadas a integrar dispositivos Wacom dentro de aplicaciones web.
¿Qué es mejor para banca: STU o DTU?
Depende del proceso. STU está especialmente orientada a captura compacta de firma. DTU ofrece mayor superficie de visualización.
Consulta Tabletas Wacom para bancos: diferencias entre STU y DTU y cuál elegir.
¿Es recomendable utilizar un único modelo?
Siempre que sea posible, reducir la diversidad simplifica soporte y mantenimiento. No obstante, algunos procesos pueden justificar dispositivos diferentes.
¿Cómo se gestionan las actualizaciones?
En despliegues empresariales deberían distribuirse mediante herramientas corporativas y, preferiblemente, de forma progresiva y controlada.
¿Qué ocurre si se avería una tableta?
El procedimiento debería permitir sustituirla rápidamente sin modificar la aplicación bancaria. Un inventario y stock de contingencia ayudan a reducir la indisponibilidad.
¿Puede utilizarse firma biométrica en Citrix?
Los entornos virtualizados deben analizarse específicamente porque la comunicación con un dispositivo físico puede requerir una arquitectura particular. Es recomendable probar el escenario real durante el piloto.
¿Puede desplegarse on-premise?
La arquitectura puede adaptarse a distintos modelos según los requisitos del proyecto y de seguridad de la entidad.
¿Qué ocurre si falla el servicio de firma?
Debe existir un plan de contingencia definido según la criticidad de la operación. Una infraestructura crítica puede requerir alta disponibilidad y redundancia.
¿Es necesario monitorizar las tabletas?
En grandes despliegues resulta conveniente disponer de información sobre dispositivos, versiones, errores y servicios para reducir el tiempo de diagnóstico.
¿Cómo se protege la biometría?
La información biométrica puede mantenerse cifrada y vinculada al documento, con controles específicos sobre su eventual recuperación.
¿Puede el mismo banco utilizar firma biométrica y firma remota?
Sí. De hecho, ambos mecanismos pueden formar parte de una estrategia omnicanal, utilizando firma manuscrita en atención presencial y firma remota en procesos a distancia.
Del piloto a una infraestructura corporativa
La diferencia entre una prueba de concepto y una solución enterprise no está en la imagen de la firma.
En ambos casos la rúbrica puede parecer idéntica.
La diferencia está detrás.
Arquitectura.
Integración.
Seguridad.
Monitorización.
Actualizaciones.
Inventario.
Alta disponibilidad.
Soporte.
Contingencia.
Evidencias.
Conservación.
Un proyecto bancario debe resolver todos estos elementos para poder funcionar durante años en una red extensa.
Por eso la selección de una solución de firma no debería basarse únicamente en una demostración donde una tableta captura correctamente un trazo.
Hay que preguntar también:
¿Cómo funcionará esta misma solución cuando tengamos 2.000 dispositivos instalados, cambie Windows, actualicemos el navegador y necesitemos mantener el servicio disponible en toda la red?
Esa es la pregunta que distingue una integración de laboratorio de una infraestructura empresarial.
Conclusión
Desplegar firma biométrica con tabletas Wacom en cientos de sucursales bancarias requiere mucho más que distribuir dispositivos.
El proyecto debe diseñarse como una infraestructura corporativa.
La aplicación bancaria debe estar desacoplada del hardware.
Los componentes deben poder distribuirse y actualizarse de forma controlada.
Los dispositivos deben identificarse y gestionarse.
La solución debe monitorizarse.
Los fallos deben contemplarse.
La biometría y los documentos deben mantenerse protegidos.
Y toda la arquitectura tiene que evolucionar durante años sin obligar a reconstruir los procesos de negocio.
Una estrategia basada en piloto, despliegue progresivo, estandarización y monitorización permite reducir significativamente el riesgo.
La experiencia de edatalia integrando firma manuscrita con dispositivos Wacom en entornos empresariales permite abordar no solo el momento de la firma, sino todo el ciclo de vida del proyecto.
Desde la integración inicial hasta el despliegue, soporte y evolución.
Para conocer el contexto completo:
edatalia, referente en firma digital manuscrita para banca en España y Latinoamérica
Firma biométrica en banca: cómo eliminar el papel en las sucursales
Tabletas Wacom para bancos: diferencias entre STU y DTU y cuál elegir
¿Estás preparando un despliegue de firma Wacom en tu red de oficinas?
En edatalia ayudamos a entidades financieras a diseñar e integrar proyectos de firma digital manuscrita y biométrica con dispositivos Wacom.
Desde una prueba piloto hasta despliegues corporativos, la solución puede integrarse con aplicaciones bancarias, CRM y gestores documentales mediante arquitecturas web, cliente-servidor y API.
Conoce nuestra tecnología:
Wacom + edatalia: soluciones de firma digital manuscrita
Para aplicaciones web:
WebSign: integración de firma manuscrita con Wacom
Y consulta la integración desde la web oficial del fabricante:
Wacom for Business: integración de edatalia con dispositivos STU y DTU
Sigue leyendo
Wacom y firma manuscrita
Tabletas Wacom para bancos: diferencias entre STU y DTU y cuál elegir
7 de septiembre de 2026
Wacom y firma manuscrita
edatalia, referente en firma digital manuscrita para la Banca en España y Latinoamérica
27 de agosto de 2026
Wacom y firma manuscrita
edatalia, referente en firma digital manuscrita para la Administración Pública en España
20 de agosto de 2026
¿Estás digitalizando tu proceso de firma?
Hablamos contigo y te enseñamos qué encaja en tu caso.