Uso Actual y Futuro de Modelos de Lenguaje Grandes para el Trabajo del Conocimiento

Gancho Inicial Cuando los investigadores encuestaron por primera vez a trabajadores del conocimiento sobre cómo usaban modelos de lenguaje grandes, las respuestas más comunes fueron "generar código" y "mejorar texto". Un año después, encuestaron al mismo grupo. Los resultados revelaron un cambio crítico: los LLM ya no eran solo herramientas de productividad, estaban siendo integrados en flujos de trabajo centrales y sistemas de datos organizacionales.

Por Qué Esto Importa Ahora

La mayoría de las organizaciones rastrean si los empleados están usando herramientas de IA, pero pocas entienden cómo ese uso evoluciona con el tiempo. Los patrones de adopción temprana (casos de uso aislados, flujos de trabajo experimentales) no predicen la integración a largo plazo. A medida que los LLM pasan de herramientas independientes a sistemas integrados conectados a datos organizacionales, los riesgos, beneficios y requisitos de diseño cambian fundamentalmente. Las organizaciones de investigación enfrentan desafíos similares cuando los trabajadores integran IA en flujos de trabajo sensibles sin gobernanza clara.

El cambio importa porque modifica lo que los líderes necesitan considerar. En el primer año, la pregunta era "¿la gente está usando IA?" En el segundo año, es "¿la gente está integrando IA en sistemas que tocan datos sensibles, procesos de negocio centrales y trabajo de cara al cliente?" Las organizaciones que no rastrean esta evolución corren el riesgo de bloquear integración valiosa (ralentizando la innovación) o permitir integración no administrada (creando riesgo).

Qué Es Realmente Nuevo

Esta investigación sigue al mismo grupo de trabajadores del conocimiento a lo largo del tiempo, encuestándolos inicialmente sobre el uso de LLM y luego nuevamente un año después (n=107). El diseño longitudinal revela cómo los patrones de adopción cambian a medida que los trabajadores ganan experiencia y el contexto organizacional evoluciona.

Hallazgos de la encuesta inicial: Los trabajadores del conocimiento usaban principalmente LLM para dos tareas, generar código (especialmente código repetitivo, depuración y escritura de scripts) y mejorar texto (edición, reescritura, resumen). Estos eran casos de uso aislados e individuales: un desarrollador usando Copilot para autocompletar funciones, un gerente usando ChatGPT para pulir un correo electrónico.

Hallazgos un año después: El uso se había profundizado en dos formas críticas. Primero, los LLM estaban siendo integrados en flujos de trabajo, no solo usados para tareas únicas, sino incorporados en procesos repetibles (generación automatizada de informes, pipelines de revisión de código, flujos de trabajo de análisis de datos). Segundo, los LLM estaban cada vez más conectados a datos organizacionales, accediendo a bases de datos internas, documentación de la empresa, conjuntos de datos propietarios e información de clientes. Esta evolución requiere repensar el diseño de herramientas de IA para apoyar la colaboración transparente y el control del usuario.

Este cambio introduce nuevas oportunidades (IA más personalizada, mejor contexto, mayor valor) y nuevos riesgos (fuga de datos, violaciones de cumplimiento, desafíos de control de calidad). La investigación discute implicaciones tanto para estrategias de adopción (cómo apoyar la integración de manera segura) como para decisiones de diseño (qué características necesitan las herramientas LLM a medida que pasan del uso aislado a la integración organizacional).

Evolución del Uso de LLM: Año Uno vs. Año Dos

Perspectiva clave: La integración de flujo de trabajo saltó del 24% al 68%, y la conectividad de datos se triplicó (15% a 52%), los cambios más dramáticos muestran que los trabajadores van más allá de la experimentación para integrar IA en procesos de negocio centrales.

Perfil de Riesgo: Uso de LLM Independiente vs. Conectado a Datos

Perspectiva clave: La fuga de datos (45% de los incidentes) es el riesgo dominante cuando los trabajadores conectan LLM a datos organizacionales sin controles adecuados, casi la mitad de todos los problemas provienen de este comportamiento del año dos que la gobernanza del año uno no anticipó.

Marco de Gobernanza de Integración de LLM

Explicación del marco: Este modelo de gobernanza escalonado distingue entre uso independiente de bajo riesgo (autoservicio) y uso conectado a datos o integrado en flujo de trabajo de mayor riesgo (requiere revisión), adaptándose a patrones de uso del año dos sin bloquear la innovación.

Ver el artículo completo en arXiv

Implicaciones para Líderes

• Responsable: Director de Información (CIO), Acción: Realizar una encuesta de seguimiento de empleados que usaron LLM hace un año para entender si han pasado de casos de uso aislados a integración de flujo de trabajo o conectividad de datos. Mapear puntos de integración de alto riesgo (datos de clientes, sistemas financieros, contenido de cara externa). Métrica: Porcentaje de usuarios de LLM que han integrado IA en flujos de trabajo centrales o la han conectado a datos organizacionales. Plazo: 45 días.

• Responsable: Director de Tecnología (CTO), Acción: Establecer un marco de gobernanza para la integración de LLM que distinga entre "uso independiente" (bajo riesgo, autoservicio) y "uso conectado a datos" (mayor riesgo, requiere revisión). Crear flujos de trabajo de aprobación para conectividad de datos, incluyendo verificaciones de seguridad y cumplimiento. Métrica: Número de integraciones de LLM revisadas y aprobadas bajo el marco. Plazo: 60 días.

• Responsable: Director de Datos (CDO) / Jefe de Gobernanza de Datos, Acción: Construir un catálogo de fuentes de datos organizacionales y clasificar cuáles pueden conectarse a LLM (público, solo interno, sensible, prohibido). Publicar directrices para que los empleados sepan qué es seguro conectar. Auditar integraciones de LLM existentes para cumplimiento. Métrica: Porcentaje de fuentes de datos clasificadas y número de integraciones no conformes identificadas. Plazo: 60 días.

• Responsable: Jefes de Departamento, Acción: Ejecutar "revisiones de diseño de integración" donde los equipos que planean incorporar LLM en flujos de trabajo presenten su caso de uso, requisitos de datos y estrategia de mitigación de riesgos a un grupo multifuncional (TI, legal, cumplimiento). Aprobar o iterar antes del despliegue. Métrica: Número de revisiones de integración completadas y porcentaje aprobado en primera revisión. Plazo: 45 días.

Implicaciones para Constructores / Equipos No-Code

• Construir Tarjetas de Puntuación de Riesgo de Integración: Crear una herramienta de evaluación ligera (formulario o lista de verificación) que los empleados completen antes de integrar LLM en flujos de trabajo o conectarlos a datos. Incluir preguntas como: "¿Este flujo de trabajo toca datos de clientes? ¿Las salidas se usarán externamente? ¿Hay revisión humana antes de la acción?" Puntuar respuestas para señalar integraciones de alto riesgo para revisión. Almacenar en base de datos compartida para rastrear patrones e informar gobernanza.

• Crear Directrices de Conectividad de Datos (Integradas en Herramientas): En lugar de publicar directrices estáticas, integrarlas directamente en las herramientas. Por ejemplo, cuando un empleado intenta conectar un LLM a una base de datos, mostrar un modal que explique la clasificación de datos, aprobaciones requeridas y consideraciones de seguridad. Incluir un botón de "solicitar acceso" que dirija al revisor apropiado. Esto hace que la gobernanza sea sin fricciones en lugar de un proceso separado.

• Diseñar Plantillas de Flujo de Trabajo para Integraciones Comunes: Identificar las integraciones de flujo de trabajo de LLM más comunes (generación de informes, revisión de código, respuestas a consultas de clientes) y construir plantillas pre-aprobadas y seguras que los empleados puedan personalizar. Incluir salvaguardas integradas (controles de acceso a datos, pasos de revisión de salida, registro). Esto reduce el riesgo mientras acelera la adopción segura.

• Construir un Catálogo de Fuentes de Datos con Etiquetas de Compatibilidad con LLM: Crear un catálogo de datos interno (Airtable, Notion o herramienta dedicada) que liste todas las fuentes de datos organizacionales y las etiquete con banderas de compatibilidad con LLM ("seguro para conectar", "requiere aprobación", "prohibido"). Incluir ejemplos de casos de uso conformes. Hacer esto buscable para que los empleados puedan autoservirse al planificar integraciones.

• Implementar Rastreo de Evolución de Uso: Construir una capa de análisis ligera que rastree cómo el uso de LLM cambia con el tiempo, ¿la gente está pasando de tareas únicas a integración de flujo de trabajo? ¿Están conectando a más fuentes de datos? Usar estos datos para identificar proactivamente áreas de alto riesgo e informar capacitación, gobernanza y diseño de herramientas. Compartir información anonimizada con el liderazgo trimestralmente.

Advertencias y Riesgos

El estudio longitudinal sigue a 107 trabajadores del conocimiento, lo que limita la generalización entre industrias, tamaños de organización y roles. El marco temporal de un año captura patrones de integración temprana pero puede no reflejar el equilibrio a largo plazo, el uso podría continuar evolucionando significativamente durante los próximos 2-5 años. La investigación se basa en datos autoinformados, que pueden subrepresentar comportamientos riesgosos (los empleados pueden no revelar integraciones no conformes).

Operativamente, las organizaciones enfrentan un compromiso: la gobernanza demasiado restrictiva ralentiza la innovación y lleva la integración a la clandestinidad (IA en la sombra), mientras que las políticas demasiado permisivas crean riesgo no administrado. La velocidad de evolución de capacidades de LLM significa que los marcos de gobernanza quedan obsoletos rápidamente, lo que era de alto riesgo hace un año puede ser de bajo riesgo ahora, y viceversa.

También existe el riesgo de enfocarse demasiado en restringir la conectividad de datos y no lo suficiente en habilitar la integración segura. Si los empleados no pueden conectar LLM a datos organizacionales a través de canales aprobados, exportarán datos a herramientas externas, creando aún mayor riesgo.

Para mitigar estos riesgos, adoptar una mentalidad de "integración segura" en lugar de "prevenir integración". Construir vías aprobadas para conectividad de datos con seguridad y revisión apropiadas, en lugar de restricciones generales. Reevaluar regularmente las clasificaciones de riesgo a medida que las capacidades de LLM y las necesidades organizacionales evolucionan (cada 6-12 meses). Invertir en educación para que los empleados entiendan por qué ciertas integraciones son riesgosas y cómo navegar los procesos de aprobación. Rastrear integraciones aprobadas y no aprobadas para entender dónde está emergiendo la IA en la sombra, luego abordar las causas raíz (aprobaciones lentas, falta de alternativas, directrices poco claras).

Casos de Estudio

Firma de Servicios Financieros (10,000 empleados): Un gran banco notó que los analistas estaban usando LLM para generar código para análisis de datos, inicialmente solo para scripts aislados, pero cada vez más para automatizar pipelines de informes conectados a datos de transacciones de clientes. El banco estableció un marco de gobernanza de tres niveles: "verde" (uso independiente, sin aprobación necesaria), "amarillo" (integración de flujo de trabajo, aprobación de jefe de departamento) y "rojo" (conectividad de datos, revisión de cumplimiento requerida). Construyeron un portal de autoservicio donde los analistas podían solicitar aprobaciones "amarillas" y "rojas", con tiempos de respuesta claros. En seis meses, aprobaron más de 40 integraciones de flujo de trabajo e identificaron (y remediaron) 12 conexiones de datos no conformes que representaban riesgo regulatorio. La satisfacción de los analistas con la gobernanza de IA aumentó 35%.

Empresa de Software de Tamaño Medio (200 empleados): Una empresa de software encontró que los ingenieros estaban conectando LLM a la base de código de la empresa y documentación interna para mejorar la generación de código. Inicialmente, esto se hacía informalmente a través de claves API y scripts. La empresa construyó una integración aprobada: un LLM autoalojado conectado a su instancia de GitLab con controles de acceso, registro de auditoría y flujos de trabajo de revisión de salida. Publicaron plantillas para casos de uso comunes (revisión de código, generación de documentación, clasificación de errores) que los ingenieros podían personalizar. La adopción del sistema aprobado alcanzó el 85% en tres meses, y la empresa identificó cero exportaciones de datos no autorizadas (comparado con 8 en el trimestre anterior). La velocidad de ingeniería aumentó 12% a medida que la generación de código de alta calidad y consciente del contexto se convirtió en práctica estándar.