Entrevista · Kevin Aragón
PRESENTACIÓN
¿Quién es Kevin Aragón y qué le atrae del trabajo con datos?
Kevin Aragón acumula más de una década entre analítica y gobierno de datos. Le atrae que ningún proyecto sea idéntico al anterior: cada organización tiene problemas, fuentes y decisiones distintas. Para él, trabajar con datos no consiste en repetir una receta, sino en razonar, descubrir hallazgos y entender el negocio lo suficiente como para convertir información dispersa en algo útil para quien debe decidir.
ANTES
Antes de incorporar inteligencia artificial, ¿cómo se definía qué información recopilar y cuánto tiempo conservarla?
El trabajo era mucho más manual y estaba limitado por la capacidad de almacenamiento disponible. Había que identificar qué historia resultaba relevante, reunir información desde varias fuentes y decidir qué debía conservarse. En analítica, Kevin señala que con frecuencia cinco o seis años ofrecen una ventana útil, aunque algunos clientes pidan más. Después venía la integración: unir datos de distintas fuentes para llevarlos a un modelo de data warehouse, estrella, copo de nieve o una estructura híbrida.
ANTES
¿Cuáles eran los principales problemas de calidad, procedencia y trazabilidad?
El problema nunca fue solamente tener pocos datos; también puede existir un enorme volumen con muy poca calidad. La primera tarea es reconocer cuáles fuentes considera confiables el cliente y cuáles son complementarias. A partir de ahí entran limpieza, transformación, reglas y gobierno de datos hasta construir una versión coherente del registro. Esa búsqueda de un Golden Record permite que la siguiente etapa -el análisis- parta de información estructurada y no de una colección de valores contradictorios.
TRANSICIÓN
¿Qué cambió primero cuando la IA comenzó a entrar en la gestión de datos?
Antes, buena parte del ETL exigía conversar con el cliente, entender su problemática y construir manualmente las transformaciones. Hoy una herramienta puede recibir contexto y proponer código, consultas o análisis en segundos. Para Kevin, la diferencia fundamental está en la velocidad, no en la responsabilidad: alguien debe revisar si la transformación es correcta, si la respuesta corresponde al problema y si la herramienta entendió realmente la estructura del negocio.
TRANSICIÓN
¿Cómo determina si un conjunto de datos es suficientemente confiable antes de utilizarlo?
La validación sigue descansando en métricas, reglas y conciliación. Si se pide analizar cinco años de ventas, no basta con aceptar el resultado porque esté bien presentado: hay que comprobar de qué tablas salió, si los totales cuadran, si las reglas de negocio se respetan y si la fuente utilizada era la correcta. La IA puede entregar una respuesta convincente aun cuando haya entendido mal la petición; por eso el profesional debe razonar sobre el resultado y no limitarse a admirar su forma.
DESPUÉS ¿Qué debería hacerse cuando los datos están incompletos, desactualizados o presentan sesgos?
Kevin propone enriquecerlos cuando sea posible. Si una dirección solo incluye departamento y municipio, pueden buscarse dimensiones u otras fuentes estructuradas que permitan completar relaciones útiles. Cuando el dato no existe o no puede recuperarse, debe quedar identificado como no asignado en lugar de inventarse. La prioridad es que la información conserve consistencia y trazabilidad. Completar un vacío con una suposición puede hacer que un reporte se vea completo, pero deja de ser confiable.
DESPUÉS ¿Cómo decidir qué información puede consultar, recordar, modificar o compartir un agente?
No todos los agentes operan bajo las mismas condiciones. Un agente local y uno conectado a un servicio público implican riesgos distintos. Hay que considerar políticas internas, legislación, ubicación de los datos y acuerdos de seguridad. Kevin utiliza el ejemplo del sector bancario: cierta información no puede abandonar determinadas jurisdicciones. En esos escenarios entran cifrado, controles de acceso y delimitación clara de qué puede consultar la herramienta y qué debe permanecer aislado.
DESPUÉS ¿Cómo deberían manejarse privacidad, consentimiento y mínimo privilegio?
La costumbre de aceptar permisos sin leerlos se vuelve especialmente peligrosa cuando una herramienta puede inferir mucho más de lo que el usuario imagina. Ubicación, rutinas y datos aparentemente pequeños pueden revelar patrones personales. A nivel empresarial sucede algo parecido: cada arquitecto, desarrollador o técnico debe responder por la información que manipula. El principio de mínimo privilegio obliga a entregar únicamente el acceso necesario para una tarea concreta y durante el tiempo necesario.
La IA puede acelerar el análisis; la confianza sigue dependiendo de datos gobernados y de una persona capaz de validar lo que recibe.
RESPONSABILIDAD ¿Qué acciones deberían conservar autorización humana obligatoria?
Kevin considera que la mayoría de decisiones relevantes necesitan supervisión. Un agente puede asumir tareas de analista, arquitecto o técnico, pero solo responde al conocimiento y contexto que recibió. No conoce por sí solo las convenciones del cliente, sus restricciones, formatos o prioridades. Puede producir un resultado técnicamente correcto y aun así ajeno a la necesidad real. Mantener una persona revisando no significa rechazar la automatización: significa colocarla dentro de un proceso responsable.
CIERRE Si una decisión automatizada resulta incorrecta, ¿quién responde?
La responsabilidad no desaparece detrás de la herramienta. Los datos organizacionales siguen perteneciendo a la organización y los datos personales requieren protección especial. Si un proyecto toma una mala decisión por una fuente deficiente o una automatización mal revisada, el equipo que gestionó y aprobó ese proceso debe responder. Para Kevin, la IA ayuda, pero no suplanta a quienes diseñan el sistema. Precisamente por eso la gobernanza sigue siendo una tarea humana.
