Chamath Palihapitiya advierte que los agentes de IA ponen en conflicto el software de adopción ascendente y la propiedad intelectual corporativa

Chamath Palihapitiya ha cuestionado la adopción ascendente de software y ha advertido que los agentes de IA convierten la experimentación informal en un posible canal de filtración de propiedad intelectual.

Una publicación de Google News puso de relieve el argumento a través de un informe de Benzinga del 6 de agosto. La afirmación subyacente es más trascendental que otra predicción de un inversor sobre la demanda de software. Palihapitiya cuestiona quién captura el conocimiento creado cuando los empleados enseñan a los agentes cómo operan sus empresas.

Tradicionalmente, el software de adopción ascendente entra en una empresa a través de usuarios individuales, luego se extiende por los equipos antes de que los ejecutivos negocien un acuerdo empresarial. Slack, Zoom, Dropbox y muchas herramientas para desarrolladores se beneficiaron de ese patrón. Los agentes de IA lo complican porque consumen documentos, correcciones, permisos y contexto operativo mientras realizan tareas.

Por tanto, el conflicto central no es simplemente entre empleados y equipos de seguridad. Es entre la adopción ascendente y el aprendizaje institucional controlado. Los empleados quieren herramientas capaces de inmediato, mientras que las empresas necesitan preservar el razonamiento, los flujos de trabajo y las excepciones que distinguen a sus negocios.

El informe de Google News convierte la adopción de software en una cuestión de propiedad

La advertencia de Palihapitiya replantea la adopción de IA como una disputa sobre quién posee el aprendizaje generado dentro de la organización de un cliente.

El informe de Google News atribuye a Palihapitiya dos preocupaciones vinculadas. En primer lugar, los agentes de IA debilitan la estrategia consolidada de venta de software mediante adopción ascendente. En segundo lugar, un despliegue mal controlado genera lo que él describe como “filtración de PI/alfa”.

En este contexto, “alfa” se refiere a la ventaja difícil de copiar de una empresa, no solo a archivos confidenciales. Incluye criterio de fijación de precios, conocimiento de los clientes, atajos operativos, métodos de investigación y las excepciones ocultas tras los procedimientos formales. Gran parte de ese conocimiento nunca aparece en un documento de políticas bien elaborado.

Una herramienta de software convencional suele recibir entradas estructuradas y devolver resultados predecibles. Un agente recibe instrucciones más amplias, elige herramientas, lee material de apoyo y completa varios pasos. A menudo necesita correcciones antes de que su resultado se ajuste a los estándares de la organización.

Esas correcciones tienen un valor inusual. Un empleado podría explicar por qué un cliente recibe una excepción, por qué un proveedor parece arriesgado o por qué un atajo técnico fracasó anteriormente. Cada explicación expone una parte del sistema práctico de toma de decisiones de la organización.

Eso no significa que cada corrección entrene el modelo fundacional de un proveedor. Los principales proveedores distinguen entre procesar datos de clientes y utilizarlos para entrenar modelos. La preocupación es más amplia que una sola opción de entrenamiento.

Un proveedor aún puede integrarse profundamente en los flujos de trabajo, las integraciones, los métodos de evaluación y los hábitos operativos del cliente. El cliente pasa entonces a depender de una capa de inteligencia externa para aplicar su conocimiento interno. Incluso sin entrenamiento del modelo, esa dependencia puede alterar el poder de negociación.

Palihapitiya ha sostenido anteriormente que las empresas corren el riesgo de ceder su ventaja mientras creen que están construyendo una estrategia de IA. Un análisis relacionado vinculó su postura con la contención del conocimiento y el despliegue gobernado.

Su interés financiero es relevante al evaluar la afirmación. Palihapitiya cofundó 8090, que desarrolla Software Factory, una capa de gestión para el desarrollo de software asistido por IA. Su posicionamiento se beneficia de las preocupaciones sobre agentes no controlados y herramientas fragmentadas.

Ese conflicto no invalida el argumento, pero exige una atribución cuidadosa. Palihapitiya no es un auditor neutral que describa una filtración confirmada. Es un inversor y proveedor que defiende una arquitectura alineada con el producto de su empresa.

La advertencia reportada tampoco aporta pruebas de que una empresa identificada haya perdido una ventaja competitiva a través de un proveedor comercial importante de IA. La “filtración de PI/alfa” sigue siendo un modelo de riesgo estratégico, no un resultado universal documentado. Los lectores deben distinguir el mecanismo de la versión más contundente de la predicción.

El mecanismo es creíble porque los agentes necesitan contexto para ser útiles. La predicción sigue siendo incierta porque los contratos, los controles técnicos y los modelos de despliegue difieren considerablemente. Esa brecha define el debate en torno a la IA empresarial.

La adopción ascendente de IA crea un tipo distinto de exposición

Los agentes de IA aumentan el valor de la experimentación ascendente, al tiempo que dificultan inventariar y gobernar sus flujos de información.

El crecimiento impulsado por el producto ofreció a los proveedores de software una vía para sortear los largos ciclos de adquisición. Un empleado podía probar una herramienta, invitar a colegas y demostrar su utilidad antes de involucrar a la alta dirección. El comprador obtenía evidencia, mientras que el proveedor conseguía defensores internos.

Esa vía funcionaba porque muchas herramientas operaban dentro de límites estrechos. Una aplicación de diseño gestionaba archivos de diseño. Un servicio de mensajería transportaba conversaciones. Un gestor de proyectos almacenaba tareas y comentarios.

Los agentes cruzan esos límites. Un agente de ventas útil podría leer correos electrónicos, buscar registros de clientes, preparar una propuesta, actualizar un embudo comercial y programar tareas de seguimiento. Un agente de programación podría inspeccionar repositorios, tickets, notas de arquitectura y registros de despliegue.

Cada conexión amplía la autoridad y el contexto del agente. También amplía las consecuencias de una acción equivocada, una cuenta comprometida o una instrucción maliciosa. La adopción ya no puede medirse solo por licencias o usuarios activos.

El Instituto Nacional de Estándares y Tecnología define a los agentes como sistemas capaces de planificar y realizar acciones autónomas en entornos reales. Su análisis de seguridad de 2026 halló un amplio consenso en que los agentes introducen amenazas diferenciadas y crean barreras para la adopción.

Una amenaza importante es la inyección indirecta de prompts. Un atacante oculta instrucciones dentro de un correo electrónico, sitio web, documento o repositorio de código que un agente lee posteriormente. El agente puede interpretar esas instrucciones como órdenes y divulgar datos o realizar una acción no deseada.

El trabajo de red teaming de NIST determinó que los principales modelos diferían sustancialmente en su resistencia a esos ataques. La capacidad del modelo no predecía de forma consistente la seguridad. Un modelo general más potente no era automáticamente el agente empresarial más seguro.

Esto importa para el despliegue ascendente porque los empleados optimizan para obtener utilidad inmediata. Pueden dar a un agente acceso a varios sistemas sin trazar cómo se mueven los datos entre ellos. Los equipos de seguridad podrían descubrir el flujo de trabajo solo después de que se vuelva operativamente importante.

El riesgo no se limita a ataques deliberados. Un agente puede incluir información sensible en un correo electrónico generado, copiar el documento equivocado a un espacio de trabajo o conservar contexto confidencial en un registro inesperado. Los errores de configuración habituales se vuelven más trascendentes cuando el software puede actuar.

Los controles tradicionales de prevención de pérdida de datos examinan archivos, mensajes y tráfico de red. Los flujos de trabajo basados en agentes añaden prompts, contexto recuperado, llamadas a herramientas, razonamiento intermedio, memoria y acciones generadas. Una empresa necesita visibilidad sobre toda esa cadena.

Los defensores de la adopción ascendente pueden sostener razonablemente que la aprobación centralizada suele avanzar con demasiada lentitud. Los empleados entienden su propio trabajo y pueden identificar usos valiosos antes que los ejecutivos. Reprimir la experimentación puede impulsar la adopción hacia cuentas personales y servicios no aprobados.

Eso genera la primera inversión en la tesis de Palihapitiya. Una prohibición estricta puede aumentar la exposición al empujar la actividad fuera de los sistemas gestionados. La vía más segura no es necesariamente menos experimentación, sino experimentación dentro de límites técnicos claros.

Un entorno aislado gobernado puede restringir los datos accesibles, las herramientas permitidas y las acciones externas. Puede exigir aprobación humana antes de enviar mensajes, modificar registros o ejecutar código. También puede conservar registros para investigación y evaluación.

Las empresas deben distinguir tres preguntas que con frecuencia se confunden. ¿Puede el proveedor entrenar con contenido del cliente? ¿Durante cuánto tiempo puede el proveedor retener ese contenido? ¿A qué puede acceder el agente y qué puede hacer durante cada sesión?

La primera se refiere al desarrollo del modelo. La segunda, al procesamiento de datos. La tercera, a la autoridad operativa, que se convierte en el problema de seguridad definitorio para los agentes.

Un proveedor puede prometer no entrenar con datos empresariales mientras un empleado sigue otorgando a su agente permisos excesivos. A la inversa, un agente bien restringido puede operar de forma segura pese a utilizar un modelo externo. La arquitectura y la gobernanza determinan la exposición real.

Por tanto, la adopción ascendente solo sobrevive si su libertad pasa a estar delimitada. Los empleados aún pueden descubrir casos de uso, pero las reglas de identidad, permisos, retención y auditoría deben preceder al despliegue amplio. La prueba espontánea de software se convierte en un experimento gestionado.

El conflicto real es el aprendizaje del cliente frente a la dependencia del proveedor

La versión más sólida del argumento de Palihapitiya se refiere a la dependencia de un ciclo de aprendizaje externo, no al robo literal de cada prompt de un cliente.

Un agente se vuelve valioso mediante la exposición repetida al trabajo de una empresa. Aprende en qué fuentes confían los empleados, qué excepciones requieren una escalada y qué resultados superan la revisión interna. Esa mejora suele provenir del sistema circundante, más que de cambios permanentes en los pesos del modelo.

El sistema circundante incluye prompts, índices de recuperación, integraciones, conjuntos de evaluación, políticas y correcciones de los usuarios. En conjunto, forman un ciclo de aprendizaje. Quien controla ese ciclo controla un activo operativo cada vez más importante.

Un sistema operado por un proveedor ofrece ventajas evidentes. El proveedor mantiene los modelos, la infraestructura de seguridad y las integraciones de producto. Los clientes evitan tener que construir cada componente por sí mismos.

La contraprestación aparece cuando cambiar de proveedor se vuelve difícil. Una empresa puede poseer sus documentos originales, pero carecer de un registro portable del comportamiento del agente, las evaluaciones, las correcciones y el historial de los flujos de trabajo. Pasar a otro proveedor implica entonces reconstruir el contexto institucional.

Esta es una forma más sutil de dependencia que un formato de archivo propietario. Los registros subyacentes pueden seguir siendo exportables, pero el comportamiento creado a su alrededor no se transfiere limpiamente. Los empleados deben enseñar al nuevo sistema las mismas reglas no escritas.

Esta preocupación se asemeja a la “paradoja inversa de la información” del CEO de Microsoft, Satya Nadella. La página de ejecutivos de Microsoft incluye su discusión del 12 de julio sobre el concepto entre sus publicaciones públicas. Nadella sostiene que los compradores de IA revelan conocimiento valioso para que la inteligencia adquirida resulte útil.

La paradoja histórica de la información se refería a que los vendedores revelaban información antes de que los compradores pudieran evaluarla. La IA invierte la dirección. Los compradores exponen conocimiento mientras evalúan y mejoran el servicio que adquieren.

La posición atribuida a Palihapitiya extiende ese razonamiento a la distribución de software. El crecimiento de abajo hacia arriba invita a los empleados a iniciar este intercambio antes de que la dirección decida dónde debe residir el conocimiento resultante. Para cuando interviene el área de compras, el flujo de trabajo puede ya depender de un proveedor.

Los proveedores de IA cuestionan la implicación de que el uso empresarial ordinario incorpore automáticamente el conocimiento de los clientes a modelos compartidos. OpenAI afirma en sus compromisos de privacidad empresarial que las entradas y salidas de negocio no se utilizan para entrenamiento de forma predeterminada.

Anthropic afirma de forma similar que no entrena modelos generativos con datos de clientes comerciales. Su explicación sobre el procesamiento comercial señala que el cliente sigue siendo el responsable del tratamiento, mientras Anthropic actúa como encargado del tratamiento.

Esos compromisos debilitan de forma sustancial las afirmaciones de filtración automática hacia el entrenamiento de modelos. Un análisis cuidadoso no puede tratar cada prompt empresarial como futuro material de entrenamiento. El tipo de contrato, la configuración de la cuenta, los programas opcionales de intercambio de datos y la superficie del producto son factores relevantes.

Sin embargo, las promesas de no entrenamiento no resuelven todas las cuestiones de propiedad. No garantizan automáticamente la portabilidad de evaluaciones, memorias de agentes, definiciones de flujos de trabajo o comentarios acumulados de los usuarios. Tampoco impiden que empleados internos introduzcan información en la cuenta equivocada.

La distinción entre servicios de consumo y empresariales es especialmente importante. Una organización puede negociar protecciones sólidas para cuentas empresariales aprobadas mientras los empleados utilizan cuentas personales fuera de esos acuerdos. La gobernanza falla cuando los controles de identidad y compras no coinciden con el comportamiento real.

La retención también difiere del entrenamiento. Un proveedor puede conservar datos temporalmente para supervisar abusos, prestar el servicio o mantener el estado del producto sin utilizarlos para mejorar un modelo compartido. Los equipos de seguridad necesitan respuestas precisas para cada endpoint y función.

El mismo escrutinio se aplica a los conectores. Puede que un modelo no se entrene con documentos recuperados, pero su agente sigue recibiendo contenido sensible durante la ejecución. Ese contenido puede aparecer en registros, resultados generados o herramientas posteriores, salvo que los controles se mantengan coherentes.

Por eso el despliegue privado no es una respuesta completa. Ejecutar un modelo abierto dentro de la infraestructura de la empresa puede reducir la exposición a terceros. También transfiere al cliente la responsabilidad de la seguridad, la evaluación, las actualizaciones, la identidad y la supervisión.

Un modelo interno con permisos amplios aún puede filtrar datos entre departamentos. Un sistema de recuperación mal configurado puede devolver los registros de un cliente a otro equipo. Un componente abierto sin parches puede introducir riesgo en la cadena de suministro.

Por tanto, la elección significativa no es entre IA externa e IA interna perfectamente segura. Es entre control externalizado y control gobernado internamente, con distintos costes y modos de fallo. La mayoría de las grandes organizaciones probablemente combinarán ambos.

Pueden dirigir tareas ordinarias a servicios externos gestionados y reservar los flujos de trabajo sensibles para sistemas aislados. También pueden mantener los prompts, las evaluaciones y las definiciones de flujos de trabajo en una capa de control independiente del modelo. Eso reduce la dependencia sin exigir que todos los modelos se ejecuten localmente.

Los trabajadores del conocimiento ya utilizan sistemas personales de conocimiento para preservar el contexto entre herramientas. Una base de conocimiento de IA estructurada aplica el mismo principio a menor escala. El usuario conserva material fuente organizado en lugar de depender por completo de un único historial de chat.

A escala empresarial, el equivalente requiere controles de acceso, procedencia y recuperación auditable. También requiere una política que defina qué conocimiento puede salir de la organización. Sin esa clasificación, «proteger el alfa» sigue siendo solo un eslogan.

La tesis de Palihapitiya presiona por igual a proveedores de SaaS y laboratorios de IA

Los agentes amenazan el motor ascendente de la industria del software, pero los requisitos de gobernanza pueden fortalecer a las plataformas consolidadas con distribución de confianza.

Los proveedores tradicionales de SaaS afrontan la presión más clara. Sus productos agrupan flujos de trabajo dentro de interfaces, permisos y bases de datos. Los agentes pueden ejecutar potencialmente esos flujos entre varios sistemas sin exigir que los usuarios pasen mucho tiempo dentro de cada aplicación.

Un representante de ventas podría pedir a un agente que prepare una renovación en lugar de abrir por separado herramientas de CRM, correo electrónico, documentos y programación. El agente se convierte en la interfaz. Las aplicaciones existentes se convierten en sistemas de registro detrás de él.

Ese cambio debilita las métricas de interacción habituales. Menos visitas a la interfaz no significan necesariamente menos valor del producto, pero dificultan demostrar la diferenciación. Los proveedores deben probar que sus datos, lógica de flujo de trabajo o permisos siguen siendo esenciales.

La adquisición de abajo hacia arriba también se vuelve más difícil cuando los equipos de seguridad controlan centralmente el acceso de los agentes. Un empleado puede probar una aplicación independiente con datos limitados. Un agente que solicita acceso al correo electrónico, código fuente o sistemas financieros recibe un escrutinio mayor.

Esto favorece a los proveedores ya integrados con los sistemas empresariales de identidad y cumplimiento. Microsoft, Google, Salesforce, ServiceNow y otros proveedores de plataformas pueden situar agentes junto a los permisos y registros existentes. Sus bases instaladas crean ventajas de distribución.

Las empresas de modelos de frontera afrontan una presión distinta. Sus mejores modelos atraen a empleados y desarrolladores, pero los compradores empresariales exigen cada vez más controles contractuales, auditabilidad, procesamiento regional y retención predecible. La calidad del modelo por sí sola no puede resolver esos requisitos.

La expansión de Anthropic mediante socios de consultoría ilustra la respuesta. En junio, la empresa dijo que más de 40.000 compañías habían solicitado participar en su programa de socios. También informó de que más de 10.000 consultores habían obtenido una certificación de Claude.

La empresa mencionó grandes despliegues o compromisos de formación en Accenture, Cognizant, Deloitte, KPMG, Infosys y PwC. Estas cifras proceden de Anthropic y describen su red de socios, no resultados de adopción auditados de forma independiente. Aun así, muestran la rapidez con la que el despliegue de agentes se está convirtiendo en un negocio de servicios.

Esto genera tensión con la advertencia de Palihapitiya. Las consultoras pueden ayudar a los clientes a implementar gobernanza, pero también profundizan el acceso del proveedor de modelos a los flujos de trabajo empresariales. El mismo socio puede reducir el riesgo técnico al tiempo que aumenta la dependencia estratégica.

La propia empresa de Palihapitiya ocupa otro lado de ese mercado. Software Factory se presenta como una capa de control entre modelos y trabajo de desarrollo de software. Esa arquitectura promete mayor control para el cliente, pero sus beneficios requieren evidencia independiente en despliegues de producción.

Un plano de control es software que gestiona cómo se seleccionan, autorizan, observan y modifican otros sistemas. En un entorno de agentes, puede dirigir tareas entre modelos preservando políticas y registros. No elimina la dependencia de los proveedores que hay debajo.

El plano de control puede convertirse por sí mismo en la nueva fuente de dependencia. Puede poseer definiciones de flujos de trabajo, datos de evaluación e historial operativo. Los clientes deberían plantear las mismas preguntas sobre portabilidad independientemente de si el proveedor vende modelos, aplicaciones u orquestación.

Los modelos de código abierto y de pesos abiertos ofrecen otra vía. Las empresas pueden desplegarlos dentro de infraestructura controlada y personalizar el sistema circundante. Esto puede limitar el procesamiento externo y generar capacidad de negociación con proveedores comerciales.

Sin embargo, el despliegue abierto exige personal especializado y trabajo operativo continuo. Los equipos deben evaluar actualizaciones de modelos, proteger sistemas de inferencia, supervisar resultados y gestionar hardware o capacidad en la nube. Las organizaciones más pequeñas pueden obtener mayor seguridad de un servicio empresarial bien gestionado.

Los proveedores de SaaS tampoco son objetivos pasivos. Pueden exponer acciones controladas mediante interfaces de programación de aplicaciones mientras mantienen permisos y pistas de auditoría en sus productos. Un agente puede entonces utilizar el software sin eludir su gobernanza.

Los proveedores también pueden hacer que los flujos de trabajo sean portables y neutrales respecto al modelo. Los clientes pueden preferir un proveedor que les permita cambiar de modelo manteniendo políticas, evaluaciones y lógica de negocio. La portabilidad se convierte en una característica de venta en lugar de una nota al pie de cumplimiento.

El resultado probable no es ni la desaparición del SaaS ni agentes ascendentes sin restricciones. Es un mercado por capas en el que los empleados eligen experiencias, las empresas controlan el acceso y las plataformas compiten por poseer la orquestación. El valor se desplaza hacia quien preserve el contexto sin atraparlo.

Ese resultado validaría parcialmente a Palihapitiya. La distribución de abajo hacia arriba perdería autonomía, mientras las plataformas de agentes gobernadas ganarían importancia. No demostraría que los proveedores externos se apropian habitualmente de la propiedad intelectual de los clientes.

La presión recae con mayor fuerza sobre productos cuya única ventaja es una interfaz conveniente sobre un modelo general. Sus funciones pueden copiarse, agruparse o ser invocadas por otro agente. Los productos con datos propietarios, flujos de trabajo de confianza o controles regulados conservan defensas más sólidas.

La afirmación de filtración aún necesita una prueba de evidencia más rigurosa

Palihapitiya identifica un problema real de gobernanza, pero la evidencia pública no demuestra una apropiación generalizada del conocimiento empresarial por parte de proveedores de modelos.

La expresión «filtración de PI/alfa» combina varios riesgos distintos. Uno es la divulgación accidental por parte de empleados. Otro es la retención por parte del proveedor. Un tercero es el entrenamiento del modelo, mientras que un cuarto es la dependencia estratégica de la infraestructura del proveedor.

Estos riesgos requieren evidencias diferentes. Un documento expuesto puede investigarse mediante registros y controles de acceso. El uso de datos de entrenamiento requiere análisis contractual y técnico. La dependencia estratégica se manifiesta mediante costes de cambio, concentración y fallos de portabilidad.

Tratar los cuatro como una única forma de filtración produce un titular llamativo, pero un plan de control débil. Un director de seguridad de la información no puede mitigar una metáfora. Los equipos deben identificar los datos, el endpoint, el usuario, el permiso y la acción posterior implicados.

El contraargumento más sólido proviene de las políticas de los proveedores. OpenAI y Anthropic afirman explícitamente que el contenido comercial de los clientes no se utiliza para el entrenamiento de modelos de forma predeterminada. Esas declaraciones son afirmaciones contractuales que los clientes pueden examinar durante las compras.

Las políticas no eliminan el riesgo de implementación. Los empleados pueden utilizar productos de consumo, activar el intercambio opcional, enviar comentarios o conectar aplicaciones no aprobadas. Los creadores de agentes de terceros también pueden operar bajo condiciones distintas a las del proveedor de modelos subyacente.

Otra incertidumbre se refiere a lo que los agentes realmente aprenden. La mayoría de los sistemas de producción no actualizan permanentemente los pesos del modelo después de cada corrección de un empleado. En su lugar, pueden almacenar historial de conversaciones, memorias, contenido recuperado o resultados de evaluación.

Esa distinción cambia el modelo de amenazas. Un flujo de trabajo retenido puede seguir siendo sensible, pero no equivale a enseñar a un modelo fundacional compartido. La cobertura informativa debe evitar insinuar un proceso técnico sin evidencia.

Los incentivos comerciales de Palihapitiya también merecen atención. Su empresa se beneficia si las empresas concluyen que la orquestación neutral respecto al modelo y la contención del conocimiento son prioridades estratégicas. Los lectores deberían considerar su advertencia como una tesis informada con un interés empresarial asociado.

La industria aún carece de mediciones estándar para la portabilidad del conocimiento. Los compradores pueden comparar precisión o latencia de modelos, pero les cuesta cuantificar cuánto aprendizaje institucional sigue siendo transferible. Esa brecha dificulta confirmar o refutar afirmaciones amplias.

Una evaluación útil comprobaría si una empresa puede sustituir a su proveedor de modelos sin reconstruir todo el flujo de trabajo. Mediría los prompts, políticas, memorias, evaluaciones, conectores y reglas de aprobación transferidos. También compararía la calidad de los resultados tras la migración.

Otra prueba consistiría en examinar si contenido sensible llega a sistemas no autorizados durante la ejecución de agentes. Los equipos de seguridad podrían insertar marcadores sintéticos en documentos controlados y rastrear dónde aparecen. Esto revelaría filtraciones operativas sin exponer secretos reales.

Las auditorías independientes también deberían examinar los compromisos de los proveedores. Los compradores necesitan pruebas de que la configuración de las cuentas, las reglas de retención y las exclusiones de entrenamiento funcionan en todos los productos conectados. Una política que cubre una API puede no cubrir un espacio de trabajo para consumidores o un plugin de terceros.

La conclusión escéptica es clara. Los agentes de IA amplían la superficie donde el conocimiento corporativo puede quedar expuesto, pero la exposición no es inevitable. La arquitectura, los términos contractuales, el comportamiento de los empleados y los controles de identidad determinan el resultado.

La advertencia de Palihapitiya es más útil como una pregunta de compras. Resulta menos convincente como una predicción concluyente de que el software de adopción ascendente ya ha fracasado. Las empresas siguen experimentando con modelos para el autoservicio gobernado.

Esta distinción importa para los empleados. Las restricciones demasiado amplias pueden reducir la productividad e incentivar el uso en la sombra. Una política exitosa proporciona a los trabajadores herramientas aprobadas con capacidad suficiente para competir con las alternativas personales.

También importa para los proveedores. El marketing basado en el miedo puede captar atención, pero puede ocultar controles concretos. Los compradores deberían exigir exportabilidad, permisos restringidos, elección de modelos, registros de auditoría y procedimientos claros ante incidentes.

La carga de la prueba recae en ambas partes. Los proveedores de modelos deben demostrar que los controles sobre los datos empresariales funcionan como prometen. Los proveedores de capas de control deben demostrar que sus sistemas reducen el riesgo sin crear otra dependencia propietaria.

Lo que los compradores empresariales deberían vigilar a continuación

La próxima etapa de este debate se decidirá mediante pruebas de portabilidad, evidencia de seguridad y cambios en las compras empresariales.

La primera señal será si los principales proveedores hacen portátil el aprendizaje de los agentes. Los clientes necesitan más que la exportación de documentos. Necesitan definiciones de flujos de trabajo, conjuntos de evaluación, correcciones, permisos y estructuras de memoria transferibles.

Si los proveedores adoptan formatos comunes, la preocupación de Palihapitiya por la dependencia se debilita. Las empresas podrían conservar su aprendizaje institucional al cambiar de modelos o plataformas de ejecución. Si la portabilidad sigue siendo limitada, el argumento sobre el control cobra fuerza.

La segunda señal será la evidencia independiente sobre la seguridad de los agentes. NIST ya ha identificado la inyección indirecta de prompts, la exfiltración de datos, la autoridad excesiva y la autorización débil como preocupaciones relevantes. Los futuros benchmarks deberían probar sistemas completos, no modelos aislados.

Una empresa no implementa un modelo por sí solo. Implementa un modelo conectado a sistemas de identidad, bases de datos, archivos y herramientas externas. Los resultados de seguridad deben reflejar ese entorno operativo.

Si las pruebas independientes muestran que los agentes restringidos resisten ataques y evitan movimientos de datos no autorizados, la experimentación ascendente puede continuar dentro de límites gestionados. Los fallos persistentes desplazarían la autoridad hacia los equipos centralizados de seguridad y compras.

La tercera señal será el comportamiento de compra empresarial. Habrá que observar si las empresas se estandarizan en una sola plataforma de agentes, adoptan capas de control neutrales respecto al modelo o mantienen varios proveedores para distintos niveles de sensibilidad. Las estructuras contractuales revelarán cómo valoran los compradores el control.

Las solicitudes de compras también serán más específicas. Los compradores preguntarán si los datos entrenan modelos, cuánto tiempo conserva el contenido cada endpoint y si los administradores pueden desactivar conectores riesgosos. Exigirán registros de auditoría a nivel de acción y puntos de control de aprobación.

La distinción entre cuentas personales y corporativas recibirá mayor atención. Las organizaciones que ofrezcan herramientas gestionadas y capaces pueden reducir la IA en la sombra. Las que se apoyen únicamente en documentos de políticas tendrán dificultades para controlar el comportamiento de los empleados.

Los resultados financieros de SaaS aportarán otra pista. Los proveedores deberían revelar si los agentes aumentan el volumen de los flujos de trabajo mientras reducen la interacción con la interfaz. También deberían explicar si los clientes pagan por resultados, acciones, consumo o licencias tradicionales.

Una disminución del crecimiento de licencias no confirmaría automáticamente el colapso del software. Los agentes pueden aumentar el valor de los registros y permisos subyacentes. El modelo de negocio puede cambiar antes de que desaparezca la categoría de producto.

Los proveedores de modelos afrontarán presión para aclarar cómo funcionan los programas opcionales de entrenamiento. Necesitarán explicaciones coherentes entre APIs, espacios de trabajo empresariales, productos de programación y servicios creados por socios. Los límites ambiguos reforzarán las preocupaciones por filtraciones.

Las empresas deberían crear ahora un inventario interno. Cada agente implementado debería contar con un responsable, fuentes de datos aprobadas, acciones permitidas, una política de retención y un proceso de reversión. Los equipos deberían registrar qué proveedor procesa cada paso.

También deberían preservar la capa de aprendizaje separada del modelo siempre que sea práctico. Los prompts, las evaluaciones, las políticas y las correcciones verificadas pueden permanecer en repositorios controlados por el cliente. Así, los modelos se convierten en componentes reemplazables, en lugar de ser el único hogar de la inteligencia operativa.

La aprobación humana sigue siendo importante para las acciones con consecuencias significativas. Enviar pagos, modificar sistemas de producción, divulgar información de clientes o tomar decisiones de empleo debería requerir autorización explícita. La autonomía solo debería ampliarse después de que un rendimiento medido lo respalde.

La nota de Google News del 6 de agosto recoge un debate que sobrevivirá a su titular. Palihapitiya cuestiona la suposición de que la adopción impulsada por empleados beneficia naturalmente al cliente. Con los agentes, cada experimento exitoso también enseña a un sistema cómo funciona la empresa.

La cuestión decisiva no es si las empresas utilizarán agentes de IA. Ya tienen fuertes incentivos para automatizar la investigación, la programación, las ventas y el trabajo administrativo. La cuestión es si pueden conservar el control sobre el conocimiento que hace eficaces a esos agentes.

Los compradores empresariales deberían plantearse una pregunta práctica antes de aprobar el próximo despliegue: si el proveedor desapareciera mañana, ¿podría la organización conservar lo que su gente enseñó al sistema?

Si la respuesta es no, la empresa ha creado algo más que una herramienta útil. Ha transferido parte de su memoria operativa a una dependencia. Esa es la advertencia detrás del titular, y merece ser puesta a prueba antes de una adopción más amplia.