Los conectores MCP de Claude Code convierten los artefactos en aplicaciones activas, pero con una salvedad sobre los permisos
Los conectores MCP de Claude Code permiten ahora que los artefactos obtengan información en tiempo real y ejecuten acciones para cada usuario, convirtiendo las interfaces generadas en software activo. Hasta este lanzamiento, los datos útiles de un artefacto quedaban, en gran medida, fijados en el momento en que su creador lo generaba o actualizaba. Anthropic anunció el cambio el 15 de julio de 2026, pero añadió una restricción importante: los artefactos compartidos públicamente no pueden utilizar esta función.
Este límite refleja la tensión que subyace a la actualización. Anthropic quiere que los artefactos se comporten como aplicaciones ligeras sin exponer las cuentas conectadas de su creador a todas las personas que abran un enlace compartido. Según la empresa, cada artefacto utiliza en su lugar las conexiones MCP del propio usuario, de modo que los resultados se limitan a la información a la que este puede acceder.
Según el anuncio de la función de Anthropic, está disponible para las suscripciones Claude Pro, Max, Team y Enterprise. Acerca los artefactos de Claude Code a los paneles internos y las aplicaciones de flujo de trabajo, aunque sin llegar a permitir un despliegue público sin restricciones. Esta combinación es más relevante que el hecho de que otro asistente de programación incorpore una integración más.
Los conectores MCP de Claude Code proporcionan datos en tiempo real a los artefactos
El cambio fundamental es sencillo: un artefacto puede solicitar ahora información actualizada cuando alguien lo consulta, en lugar de permanecer como un producto estático de la sesión en la que fue creado.
Un artefacto es una interfaz interactiva, un documento, una visualización o una aplicación generada mediante Claude. Puede incluir controles funcionales y código de interfaz ejecutable, en lugar de limitarse a texto conversacional. Incorporar llamadas a conectores permite que esa interfaz acceda a sistemas externos.
MCP, o Model Context Protocol, es un estándar abierto que conecta aplicaciones de IA con fuentes de datos, herramientas y flujos de trabajo externos. La descripción general de MCP oficial señala que estos sistemas pueden incluir bases de datos, archivos locales, herramientas de búsqueda, calendarios e instrucciones especializadas.
El protocolo separa la aplicación que solicita una capacidad del servidor que la proporciona. Un servidor MCP puede exponer recursos, como documentos, y herramientas, como consultas a bases de datos o acciones de flujo de trabajo. Un cliente compatible puede descubrir e invocar esas capacidades mediante una interfaz común.
Claude Code ya admitía conexiones MCP durante las sesiones de programación. Un desarrollador podía permitir que el agente de programación examinara un gestor de incidencias, consultara documentación o interactuara con otro servicio autorizado. El nuevo lanzamiento traslada esa capacidad al artefacto creado durante la sesión.
Esta diferencia cambia el momento en que se ejecuta un conector. El creador ya no necesita volver a abrir Claude Code y regenerar un panel cada vez que cambian sus datos de origen. El artefacto publicado puede solicitar información actualizada cuando un usuario autorizado lo abre o lo utiliza.
Pensemos en un panel sobre el estado de ingeniería elaborado a partir de la actividad de un repositorio, registros de incidentes y un gestor de proyectos. Un artefacto estático podría mostrar los datos disponibles durante su creación. Una versión con conectores puede solicitar una vista actualizada cada vez que un ingeniero la abre.
El mismo patrón se aplica a una aplicación operativa. Un usuario podría consultar una cola, seleccionar un elemento e invocar una acción autorizada mediante una herramienta MCP. La interfaz se convierte en un cliente de los servicios existentes, no solo en un resumen visual.
Anthropic afirma que el artefacto puede obtener información y ejecutar acciones bajo demanda para cada usuario. Esta segunda capacidad tiene consecuencias más profundas que disponer de gráficos actualizados. Leer datos actuales mejora su vigencia, mientras que las herramientas con capacidad de escritura pueden modificar registros o iniciar flujos de trabajo.
El anuncio no ofreció una especificación pública completa de las llamadas a conectores realizadas desde artefactos. Tampoco detalló los límites de uso, la compatibilidad de los conectores, el comportamiento de los registros ni cada uno de los pasos de aprobación. Estas incógnitas aconsejan evaluar la función con cautela, en lugar de adoptarla automáticamente en entornos de producción.
Aun así, el mecanismo está lo bastante claro como para constatar el cambio. Los conectores MCP de Claude Code ya no se limitan al agente que crea el software. También pueden formar parte del software que produce ese agente.
Un mismo artefacto puede servir a distintos usuarios
El diseño de Anthropic convierte la identidad del usuario en la fuente de acceso, lo que impide que el creador de un artefacto ceda de forma inadvertida sus permisos personales a otras personas.
Este modelo separa la interfaz del artefacto de las credenciales utilizadas durante la ejecución. El creador puede definir qué intenta solicitar la aplicación, pero cada usuario aporta la conexión pertinente y su propio contexto de autorización. Por tanto, los datos obtenidos deberían reflejar los permisos de acceso existentes de ese usuario.
Así, un responsable de ventas y un representante comercial podrían abrir el mismo panel, pero recibir registros diferentes. El responsable podría ver los totales regionales, mientras que el representante únicamente vería las cuentas que tiene asignadas. El artefacto permanece idéntico, pero el sistema conectado aplica permisos distintos.
Esto resulta más útil que generar paneles separados para cada función. También evita insertar las credenciales del creador en el código generado, lo que plantearía un evidente problema de seguridad y mantenimiento. Las credenciales deben permanecer fuera del artefacto y bajo el flujo de autorización del conector.
La arquitectura se asemeja a patrones consolidados en las aplicaciones empresariales. Una interfaz compartida solicita datos a un servicio protegido, mientras que la identidad y la autorización determinan la respuesta. La interfaz generada por Claude modifica el proceso de creación, pero no elimina la necesidad de controlar el acceso.
Este detalle también explica por qué se excluyen los artefactos compartidos públicamente. Un visitante anónimo carece del contexto autenticado de Claude y de la relación con el conector que exige la función. Permitir que páginas públicas activaran llamadas a conectores privados crearía límites difíciles de gestionar en materia de consentimiento y credenciales.
La restricción reduce el mercado inmediato. Tal como se ha descrito hasta ahora, estos artefactos son más apropiados para flujos de trabajo personales autenticados, herramientas de equipo y aplicaciones internas que para servicios públicos dirigidos a consumidores. Actualmente, una empresa no puede construir un portal público sin restricciones en torno a esta capacidad.
Para los equipos internos, este límite puede ser una ventaja en lugar de un inconveniente. Muchas aplicaciones útiles ya dependen de la identidad de los empleados y de datos organizativos privados. Los paneles de proyectos, las colas de aprobación, los resúmenes de clientes y las interfaces de investigación rara vez deberían estar disponibles mediante enlaces públicos.
El modelo basado en el usuario también reduce el trabajo de actualización. El creador construye la interfaz una sola vez, mientras que cada usuario solicita resultados actualizados a través de sus propias conexiones. El creador no tiene que ejecutar otra sesión de generación cada vez que alguien necesita información actual.
Sin embargo, limitar el acceso al contexto de cada usuario no convierte automáticamente en segura cualquier aplicación generada. Un artefacto puede solicitar una herramienta con permisos excesivamente amplios o presentar una acción sin el contexto suficiente. Un usuario también puede autorizar el acceso sin comprender qué hará la interfaz generada.
Por tanto, las organizaciones deberían distinguir entre autorización e intención. Un conector puede confirmar correctamente que una persona tiene permiso para actualizar un registro. Esa comprobación no garantiza que el usuario haya entendido el botón del artefacto, la consulta generada o la acción propuesta.
La ventaja práctica sigue siendo considerable. Un equipo puede distribuir una única interfaz generada sin compartir las credenciales de una persona ni mantener copias independientes para cada usuario. Los conectores MCP de Claude Code hacen posible este modelo dentro del entorno de artefactos de Anthropic.
El verdadero rival es el prototipo estático
Anthropic no se limita aquí a competir con otro asistente de programación; cuestiona la frontera entre los prototipos generados y las aplicaciones internas que se mantienen a largo plazo.
Las herramientas de programación con IA aprendieron a producir paneles atractivos antes de ser capaces de alimentarlos con datos actuales y sujetos a controles. Una interfaz generada podía parecer terminada mientras dependía de valores de muestra, exportaciones pegadas o información confinada en una conversación.
Esta carencia daba lugar a un problema habitual en las demostraciones. Un prototipo funcionaba durante una presentación, pero perdía valor cuando cambiaban sus datos de origen. Convertirlo en una herramienta interna duradera seguía exigiendo autenticación, integración con API, alojamiento, permisos, supervisión y mantenimiento.
Los conectores MCP de Claude Code eliminan parte de ese trabajo de integración. Si una organización ya expone sistemas autorizados mediante MCP, un artefacto puede invocar esas capacidades a través de un protocolo común. El desarrollador no necesita crear una interfaz personalizada diferente para cada servicio.
Anthropic presentó originalmente MCP en noviembre de 2024 como un estándar para conectar asistentes de IA con datos y herramientas. El lanzamiento del protocolo describía una arquitectura de dos partes, en la que los servidores exponen capacidades y las aplicaciones de IA actúan como clientes.
Desde entonces, el protocolo se ha extendido más allá de los productos de Anthropic. La empresa donó MCP a la Agentic AI Foundation de la Linux Foundation en diciembre de 2025. En su anuncio sobre la fundación, afirmó que ChatGPT, Gemini, Microsoft Copilot, Cursor y Visual Studio Code habían adoptado el estándar.
Esta adopción es importante porque la disponibilidad de conectores determina la utilidad de los artefactos activos. Un estándar compatible con varios clientes ofrece a los proveedores de servicios más incentivos para mantener servidores compatibles. También aumenta las posibilidades de que las empresas reutilicen su trabajo de integración.
GitHub ofrece una referencia competitiva directa. Su guía de MCP para Copilot oficial explica cómo los desarrolladores pueden ampliar Copilot Chat mediante servidores MCP. Las empresas también pueden habilitar o deshabilitar el uso de MCP mediante políticas.
La diferencia reside en la superficie de producto que recibe el conector. Los agentes de programación suelen invocar herramientas MCP mientras ayudan a un desarrollador. Anthropic permite que un artefacto generado invoque posteriormente esas herramientas cuando otra persona interactúa con la interfaz terminada.
Esto acerca el resultado a una plataforma de aplicaciones internas. El artefacto contiene la experiencia de usuario, MCP aporta capacidades estandarizadas y la cuenta del usuario proporciona la identidad. Claude Code sigue siendo el entorno de creación, pero el resultado continúa funcionando fuera del intercambio de programación original.
Esto no vuelve obsoleto el desarrollo convencional de aplicaciones. Los sistemas complejos siguen necesitando pruebas, observabilidad, control de versiones, controles de despliegue, revisión de accesibilidad y responsables a largo plazo. Los artefactos generados también continúan sujetos al entorno de ejecución y al modelo de uso compartido de Anthropic.
En cambio, la actualización apunta al amplio espacio que existe entre una maqueta y una aplicación de producción. Muchas necesidades internas se limitan a una audiencia reducida, una fuente de datos existente y un flujo de trabajo acotado. Esos proyectos suelen quedar pendientes porque su valor no justifica un ciclo de desarrollo específico.
Un responsable de producto podría necesitar una vista semanal del riesgo de lanzamiento elaborada a partir de incidencias y actividad del repositorio. Un investigador podría necesitar una interfaz de búsqueda sobre materiales de estudio autorizados. Un responsable de ingeniería podría necesitar una sola pantalla que muestre incidentes, despliegues y tareas de seguimiento asignadas.
Los equipos ya pueden construir estos sistemas con las herramientas existentes. La cuestión es si Claude Code puede reducir la distancia entre una necesidad expresada y una interfaz utilizable y sujeta a controles. La respuesta depende menos de la generación de interfaces que de la fiabilidad de los conectores.
Para los equipos que exploran flujos de trabajo internos asistidos por IA, una base de conocimiento de ingeniería bien mantenida también permite que el material de referencia siga siendo localizable mediante búsquedas. Los artefactos con conectores pueden centrarse entonces en acciones y vistas creadas en torno a información sujeta a controles de gobernanza.
Por tanto, la mayor presión competitiva recae en los prototipos estáticos y en el trabajo de integración fragmentado. Anthropic apuesta por que un artefacto siga recuperando datos una vez finalizada la sesión en la que fue creado. Es una aspiración más acotada que sustituir a las plataformas de herramientas internas, pero también más creíble.
Las acciones en tiempo real amplían el perímetro de seguridad
Cada llamada a un conector convierte el código de interfaz generado en un posible evento de acceso a datos o de ejecución de flujos de trabajo, por lo que el lanzamiento amplía tanto la utilidad como el riesgo.
El primer problema es el alcance de las herramientas. Los servidores MCP pueden exponer operaciones de lectura, de escritura o ambas. Un panel que consulta métricas aprobadas presenta un perfil de riesgo distinto al de un artefacto capaz de modificar cuentas, enviar mensajes o activar despliegues.
El segundo problema es la intención generada. Claude puede producir una interfaz cuya etiqueta visible no comunique por completo la llamada a la herramienta subyacente. Un botón marcado como “resolver” podría actualizar varios registros, cerrar un incidente o notificar a otro sistema.
El tercer problema es la confianza en el conector. MCP estandariza la comunicación, pero no garantiza que todos los servidores sean seguros o estén implementados correctamente. Las organizaciones siguen teniendo que evaluar al operador del servidor, el proceso de autenticación, los permisos solicitados y las prácticas de tratamiento de datos.
El cuarto problema es la manipulación mediante instrucciones y contenidos. Un artefacto puede mostrar información recuperada de sistemas externos, y esa información puede contener instrucciones engañosas o maliciosas. Las aplicaciones deben tratar el contenido externo como datos, no como directrices operativas fiables.
El quinto problema concierne a la visibilidad. Los equipos necesitan registros que indiquen qué artefacto solicitó una herramienta, qué usuario la autorizó, qué operación se ejecutó y si el servicio la aceptó. Sin pistas de auditoría útiles, investigar una acción inesperada resulta mucho más difícil.
Los materiales públicos de Anthropic ya muestran que la gobernanza de los conectores está evolucionando. Su documentación sobre autorización empresarial describe el acceso a conectores aprovisionado de forma centralizada mediante el proveedor de identidad de una organización.
Ese sistema ofrece a los administradores una forma de autorizar conectores seleccionados y vincular el acceso con las identidades organizativas existentes. Anthropic afirma que los administradores pueden aprovisionar conectores para grupos y revocar el acceso mediante cambios en el ciclo de vida de las identidades. Algunos controles basados en roles todavía se describen como funciones futuras.
Esos controles determinan quién puede conectarse a un servicio. Sin embargo, las empresas aún necesitan saber si los administradores pueden gobernar por separado el uso de los artefactos, restringir herramientas concretas o exigir confirmación para acciones sensibles. El anuncio, por sí solo, no resuelve esas cuestiones.
La exclusión del uso compartido público es la protección más visible. Cierra la vía más evidente para distribuir ampliamente un artefacto y pedir a visitantes anónimos que invoquen servicios autenticados. Aun así, el uso compartido autenticado puede llegar a un público interno numeroso.
Por tanto, una aplicación generada debe someterse a una revisión proporcional a sus capacidades. Un panel de solo lectura basado en datos operativos poco sensibles requiere menos escrutinio que una interfaz capaz de modificar registros de clientes. Ambos deben tener un responsable designado y una finalidad definida.
Los equipos deberían comenzar con conectores de alcance limitado y herramientas de solo lectura. Pueden comprobar que los permisos de los usuarios producen los resultados esperados antes de añadir acciones. Las herramientas sensibles deberían exigir una confirmación explícita y mostrar claramente el objetivo, los parámetros y el efecto previsto.
Las pruebas deben incluir varias identidades. Que la experiencia del creador sea satisfactoria no demuestra que otro usuario solo pueda ver la información para la que está autorizado. Los revisores deberían probar el acceso esperado, el acceso denegado, las autorizaciones caducadas, las cuentas revocadas y los fallos del conector.
La gestión de errores también es importante. Un panel debería distinguir entre la falta de permisos y la ausencia de datos, y las acciones fallidas no deberían aparecer como completadas. Las interfaces generadas suelen optimizarse para el escenario ideal, salvo que se les solicite explícitamente gestionar los fallos.
La minimización de datos aporta otra defensa práctica. Un artefacto debería solicitar únicamente los campos necesarios para su finalidad, en lugar de recuperar registros completos y filtrarlos en la interfaz. La aplicación de controles en el servidor sigue siendo más fiable que ocultar información después de recuperarla.
El valor de la función aumenta con la sensibilidad de los sistemas empresariales conectados, pero también lo hace su riesgo. Los conectores MCP de Claude Code reducen la fricción de integración. No reducen las consecuencias de una acción mal delimitada o de una consulta autorizada incorrectamente.
Lo que los conectores MCP de Claude Code todavía no pueden sustituir
Los artefactos con conectores acortan el camino hacia un software útil, pero no proporcionan el modelo operativo completo que requieren los sistemas de producción duraderos.
Una aplicación de producción necesita un control de versiones predecible. Los equipos deben saber qué código de interfaz se está ejecutando, quién lo modificó y cómo restaurar un estado anterior. Los artefactos generados necesitan una disciplina comparable cuando los empleados dependen de ellos para tomar decisiones cotidianas.
Las aplicaciones también necesitan expectativas claras sobre el nivel de servicio. Un conector puede dejar de estar disponible, quedar sujeto a límites de uso o ser modificado por su proveedor. El artefacto debe gestionar esas situaciones sin presentar información desactualizada como si fuera vigente ni dejar a los usuarios con dudas sobre si las acciones se completaron.
Los cambios de esquema plantean otro problema. Una herramienta MCP puede modificar sus requisitos de entrada o los campos que devuelve. Una interfaz generada a partir de una definición anterior puede fallar o interpretar incorrectamente las nuevas respuestas si nadie mantiene la integración.
Los flujos de trabajo de larga duración siguen constituyendo una categoría aparte. Un artefacto puede iniciar una acción, pero los procesos empresariales complejos suelen requerir colas, reintentos, aprobaciones, ejecución programada y gestión de estados. Esas responsabilidades normalmente corresponden a servicios de backend.
Los requisitos de cumplimiento normativo añaden más limitaciones. Los equipos regulados pueden necesitar políticas de retención, controles regionales, revisiones formales de acceso, registros de auditoría detallados o cambios de software validados. Una práctica solicitud de consentimiento a nivel de usuario no satisface por sí sola esas obligaciones.
La distribución pública tampoco está disponible para los artefactos con conectores. Una empresa que desarrolle una aplicación orientada al cliente seguirá necesitando una arquitectura de alojamiento adecuada, autenticación independiente, controles contra abusos y procesos de soporte. La restricción de Anthropic mantiene los artefactos centrados en el uso autenticado.
Los mejores casos de uso iniciales son limitados y reversibles. Implican un público conocido, un número reducido de fuentes de datos aprobadas y acciones que puedan revisarse o deshacerse. Los paneles internos encajan mejor en este patrón que las operaciones financieras autónomas.
Una evaluación útil debe comprobar si el artefacto falla de forma segura. Si un conector desaparece, ¿explica la interfaz lo ocurrido? Si un usuario carece de permisos, ¿se detiene correctamente? Si una acción agota el tiempo de espera, ¿puede el usuario verificar su estado antes de volver a intentarlo?
Otra prueba se refiere a la responsabilidad. Alguien debe seguir haciéndose cargo después de la sesión inicial de generación. Esa persona debería conocer los sistemas de origen, aprobar los cambios, supervisar el uso y decidir cuándo el artefacto ha dejado de cumplir su finalidad original.
Esta responsabilidad limita las afirmaciones más ambiciosas sobre el ahorro de costes asociado a las aplicaciones generadas por IA. Una creación más rápida no elimina el mantenimiento. Cambia dónde se realiza y qué capacidades necesita el equipo responsable.
Aun así, la función puede mejorar la rentabilidad de las herramientas pequeñas. Reutilizar un conector aprobado elimina tareas de integración repetitivas, mientras que las interfaces generadas reducen el trabajo de frontend. Ese ahorro es significativo cuando el flujo de trabajo se mantiene dentro de los límites del entorno de ejecución de los artefactos.
Las organizaciones deberían comparar este enfoque con tres alternativas: un informe estático, una plataforma consolidada de herramientas internas y una aplicación personalizada. El artefacto se impone cuando la actualización de los datos es importante, el alcance permanece limitado y una infraestructura completa de aplicaciones resultaría excesiva.
Pierde ventaja cuando el acceso público, una fiabilidad estricta, una orquestación extensa o el alojamiento independiente se vuelven imprescindibles. Eso no supone un fracaso de la función. Es la frontera entre una interfaz conectada y ligera y un producto de software gestionado.
Por tanto, los conectores MCP de Claude Code ocupan una capa intermedia práctica. Son más capaces que los resultados generados estáticos, pero menos autónomos que las aplicaciones desplegadas con backends dedicados. Los equipos que respeten esa frontera obtendrán resultados más fiables.
Tres señales mostrarán si el modelo funciona
La siguiente fase depende de la gobernanza, la adopción real y el comportamiento de los conectores bajo cargas de trabajo cotidianas, más que de otra demostración impecable.
La primera señal será una documentación más detallada por parte de Anthropic. Los equipos necesitan descripciones precisas de los flujos de consentimiento, los tipos de conectores compatibles, los límites de llamadas a herramientas, el registro de actividad, la gestión de errores y los controles administrativos. Las carencias documentales son especialmente importantes cuando los artefactos pueden ejecutar acciones de escritura.
Unos controles de políticas más sólidos reforzarían la orientación de Anthropic hacia las aplicaciones internas. Los administradores deberían poder determinar a qué conectores pueden llamar los artefactos, si se permiten herramientas de escritura y qué usuarios pueden publicar artefactos conectados.
Si esos controles llegan pronto, la función será más fácil de evaluar para los entornos Team y Enterprise. Si la gobernanza sigue dependiendo principalmente de los usuarios, los equipos de seguridad limitarán los despliegues a conectores de bajo riesgo o a grupos piloto aislados.
La segunda señal será un uso interno sostenido. La evidencia importante no será el número de artefactos generados, sino si los equipos siguen utilizándolos después de los experimentos iniciales y asignan responsables para mantenerlos.
Un uso reiterado indicaría que el modelo basado en los permisos del usuario resuelve un verdadero problema de distribución. Una baja retención sugeriría que la configuración de conectores, los permisos, la fiabilidad o el mantenimiento de las interfaces todavía generan demasiada fricción.
Los casos de éxito también deberían volverse más específicos. Habrá que observar si los equipos utilizan artefactos conectados para gestionar el estado de las versiones, las operaciones con clientes, los procesos de investigación, la respuesta a incidentes o las aprobaciones rutinarias. Los flujos de trabajo concretos revelan más que las demostraciones genéricas de paneles.
La tercera señal será cómo los entornos de desarrollo de la competencia exponen las capacidades de MCP en los resultados generados. GitHub, Microsoft, OpenAI, Google, Cursor y otros proveedores ya participan en el ecosistema más amplio de MCP. Pueden aplicar el protocolo a distintos entornos de ejecución y modelos de uso compartido.
Un competidor que combine interfaces generadas, políticas empresariales y despliegue independiente debilitaría la posición de Anthropic. En cambio, una adopción más amplia de clientes MCP similares a los artefactos validaría la categoría de producto, aunque redujera la diferenciación a nivel de protocolo.
La ventaja de Anthropic no consiste en ser el propietario permanente de MCP. La donación del protocolo reforzó su legitimidad como infraestructura compartida, pero también facilitó su adopción por parte de los competidores. Anthropic debe diferenciarse mediante la experiencia de los artefactos, la gobernanza y la fiabilidad.
Para los desarrolladores, la acción inmediata consiste en crear un prototipo controlado. Elija un conector de solo lectura, un flujo de trabajo limitado y al menos dos identidades de prueba. Verifique la actualización de los datos, el acceso denegado, el acceso revocado, los fallos del conector y la visibilidad de la auditoría antes de habilitar acciones.
Para los compradores empresariales, conviene plantear una pregunta más precisa que si la función es compatible con MCP. Pregunten quién aprueba cada conector, qué herramientas puede invocar un artefacto, cómo confirman los usuarios las acciones y dónde aparece cada invocación en los registros de auditoría.
Para los trabajadores del conocimiento, la oportunidad es igual de concreta. Un artefacto útil puede presentar información actualizada mediante una interfaz específica para cada tarea, sin exigir instrucciones reiteradas. Su valor procede de un acceso fiable y de acciones claras, no de la novedad visual.
Los conectores MCP de Claude Code han llevado los artefactos más allá de las demostraciones estáticas, pero Anthropic los ha mantenido deliberadamente tras barreras de autenticación. La próxima prueba será comprobar si los equipos pueden convertir esa barrera en software interno fiable.
El punto de partida debe ser un flujo de trabajo en el que los datos desactualizados generen fricciones evidentes. Después, habrá que determinar si un artefacto con conectores se mantiene preciso, comprensible y controlable para varios usuarios. Si es así, Anthropic habrá creado una nueva capa de aplicaciones creíble.
