Resumen

  • El asunto estratégico 560 del W3C sigue abierto, identifica WebMCP como el cambio sustantivo de la carta y no fija una fecha para terminar su refinamiento.
  • La pull request 829 incorpora integración nativa de agentes, registro imperativo de herramientas JavaScript y una vía declarativa basada en formularios HTML; WebMCP figura como entregable provisional.
  • El parche no modifica la lista de coordinaciones nombradas, aunque el propio asunto solicita revisión de HTML, ARIA, TAG, SING y participantes de privacidad.
  • WebKit mantiene una posición contraria, Mozilla una posición neutral, APA no respalda el informe actual y el análisis de amenazas continúa. Ninguno de esos registros decide la carta.
  • Antes de la revisión del Advisory Committee convendría publicar una matriz de alcance y responsables que distinga propiedad, dependencia, consulta y revisión sin conceder vetos automáticos.

La autoridad propuesta está en el detalle del diff

La situación documental exige verbos precisos. El asunto 560 se abrió el 9 de junio de 2026, sigue abierto y marca como desconocido el final esperado del refinamiento. La pull request 829 también permanece abierta y sin fusionar; contiene un único commit de cabecera fechado ese mismo día. Por tanto, se puede hablar de alcance propuesto, no de carta aprobada, estándar adoptado ni implementación acordada.

El cambio, aun provisional, es profundo. La carta vigente se concentra en inferencia de aprendizaje automático: WebNN como API de bajo nivel, acceso a aceleradores y posible carga de modelos. El parche pluraliza las API y añade una integración nativa de agentes de IA en el navegador. Con ello aparece una nueva superficie normativa.

En la vía imperativa, un sitio podría registrar, actualizar y retirar funciones JavaScript presentadas como herramientas estructuradas, con descripciones y entradas similares a esquemas. En la vía declarativa, elementos HTML —sobre todo formularios— podrían llevar anotaciones que permitan a un agente descubrir acciones. El navegador mediaría la interacción, aplicaría límites de mismo origen y autorización del usuario, y podría activar funciones de la página.

Eso conecta cuatro planos que la carta anterior no necesitaba unir del mismo modo: ejecución en el navegador, semántica de HTML, experiencia accesible y límites de confianza del agente. Llamar “tentative” al entregable preserva los filtros posteriores: progreso de incubación, interés de varios implementadores y consenso del Working Group. No convierte la ampliación de autoridad en una corrección editorial.

El mapa de coordinación no acompaña al nuevo alcance

El parche cambia alcance y entregables, pero no la sección de coordinación técnica adicional. El borrador público conserva la lista heredada: Web Machine Learning Community Group, GPU for the Web Working Group, WebAssembly Community Group, WebRTC Working Group y Technical Architecture Group; fuera del W3C nombra a ECMA TC39.

La carta contiene además una obligación general de revisión horizontal para accesibilidad, internacionalización, privacidad, seguridad y arquitectura. Esa cláusula importa: sería incorrecto afirmar que el proceso ignora esas materias. Pero una obligación general de revisar y una dependencia concreta cumplen funciones diferentes.

Una revisión horizontal pregunta si el texto respeta requisitos transversales. Una relación de dependencia explica qué grupo conserva la responsabilidad sobre una capa, qué entregable puede verse afectado y por qué canal se comunican los cambios. El dueño de una especificación, un coeditor, un grupo consultado y un revisor horizontal no tienen el mismo poder. Cuando una propuesta convierte formularios HTML en una interfaz para agentes y plantea dudas sobre ARIA o el árbol de accesibilidad, la carta debería distinguirlos.

El asunto estratégico ya enumera gran parte del circuito: HTML, ARIA, TAG, SING y privacidad. Así, el problema no es una supuesta ausencia de conversación. Los comentarios públicos muestran lo contrario. El problema es que la actividad de revisión aún no se proyecta en la carta como una tabla de responsables, dependencias y mecanismos de comunicación.

Cuatro expedientes, cuatro estados institucionales

La posición de WebKit es de oposición. Su análisis sostiene que WebMCP puede crear una superficie paralela para agentes, que parte de las carencias debería resolverse en semánticas comunes de HTML y accesibilidad, y que el lugar de Machine Learning no sería el adecuado para decidir la evolución de esas capas. Un representante de Apple añadió en la pull request que esperaría formular una objeción formal si el cambio se fusionara y mostró apertura a otra sede. Es una advertencia seria, pero no es un veto ni una decisión del W3C.

Mozilla registra una posición neutral. Reconoce que la abstracción puede ser útil, pero mantiene preguntas sobre riesgos, nombres, alcance del ecosistema y relación entre los diseños imperativo y declarativo. Neutral no significa apoyo de implementación; tampoco significa rechazo. Describe una evaluación que permanece abierta.

El comentario de Accessible Platform Architectures del 27 de agosto es más concreto. APA ve posibilidades experimentales, entre ellas beneficios para ciertas necesidades cognitivas, pero no apoya el informe actual del Community Group. Pide que el usuario pueda descubrir, examinar, autorizar, cancelar y deshacer acciones; separa la información de WebMCP del árbol de accesibilidad y advierte del riesgo de que las capacidades para humanos y agentes se desalineen. Considera más prometedora la vía declarativa sin elevarla todavía a solución madura.

El registro de seguridad se encuentra en otra fase. Las actas del Security Interest Group de julio estudian límites entre sitios, navegadores, agentes y usuarios; contenido de herramientas, origen cruzado, visibilidad y duración. Es un modelo de amenazas en construcción, no una certificación de seguridad ni un rechazo.

Estas diferencias son información de gobernanza. Fundir oposición, neutralidad, no apoyo condicionado y análisis en curso en una sola “opinión de la comunidad” produciría una mayoría imaginaria.

El Proceso exige dependencias y tratamiento de comentarios

El Proceso del W3C obliga a una carta a definir alcance y entregables, identificar dependencias con otros grupos y describir mecanismos de comunicación cuando otros grupos dependen del trabajo. Antes de la revisión del Advisory Committee, la revisión amplia debe completarse y las cuestiones contra el borrador deben recibir una respuesta formal, con resoluciones rastreadas y objeciones persistentes destacadas.

Nada de esto implica que cada revisor se convierta en copropietario o que pueda bloquear unilateralmente el trabajo. La solución no es un registro de vetos. Es una estructura que permita responder tres preguntas: quién posee la capa afectada, cómo se comunica una incompatibilidad y qué autoridad dispone el desacuerdo.

La precisión es especialmente importante ante una ampliación. Incorporar un entregable en vía Recommendation fuera del alcance de un entregable existente es un cambio mayor de carta y requiere revisión del Advisory Committee. Mientras ese proceso no concluya, la carta activa —vigente hasta el 30 de abril de 2027— sigue siendo el mandato operativo y continúa centrada en el trabajo de aprendizaje automático.

Una matriz de alcance y responsables

El expediente podría añadir una matriz pública y versionada. Cada fila señalaría la revisión de carta y el commit inmutable, la superficie normativa propuesta, la capa de plataforma afectada, la autoridad que se solicita para el Working Group y el grupo dependiente, custodio o revisor. También registraría el rol exacto —copropietario, dependencia, enlace, consultado o revisor horizontal—, el canal de comunicación, la solicitud y respuesta de revisión, la objeción no resuelta, el criterio de adopción o traslado, el estado de madurez y patentes, y el siguiente actor responsable.

La fila de formularios declarativos podría nombrar la capa HTML sin suponer que todo participante de HTML coedita WebMCP. La fila de accesibilidad separaría la responsabilidad de ARIA o del árbol accesible de la revisión horizontal de APA. La fila de seguridad indicaría “modelo de amenazas en curso”, no una marca verde. Las posiciones de navegadores quedarían separadas del consenso del grupo y de la aprobación del W3C.

La matriz no responde si WebMCP debe vivir en Web Machine Learning, en un grupo nuevo, en un reparto entre organismos o únicamente en incubación. Hace visible quién debe responder antes de que esa elección quede enterrada bajo la palabra “coordinación”.

La disciplina de especificación mínima de Heng Lu pone un límite útil: el registro común debe contener solo las uniones necesarias para coordinar, mientras las decisiones futuras permanecen en manos de quienes poseen cada capa. El objetivo no es centralizar la Web agéntica, sino evitar que una carta herede autoridad adyacente por silencio.

Lo que la evidencia no demuestra

Que un grupo no figure en la lista no prueba que no haya reuniones o conversaciones privadas. La oposición de Apple no demuestra un rechazo del W3C. La neutralidad de Mozilla no demuestra consenso entre implementadores. La observación de APA no invalida todos los diseños posibles, y las actas de seguridad no establecen que WebMCP sea inseguro.

Tampoco existe prueba de adopción, interoperabilidad o despliegue. WebMCP continúa como informe de Community Group. El parche sigue abierto. La incubación, la inclusión en una carta, la adopción como trabajo del grupo, un Working Draft y una Recommendation son estados institucionales distintos.

El hecho verificable es más estrecho: la propuesta otorgaría a un Working Group capacidad para explorar superficies vinculadas con HTML y agentes de navegador, mientras su lista nominal de coordinación permanece en el diseño anterior. Las revisiones ya hacen visibles a los actores y las dudas. Falta convertir esa visibilidad en roles y disposiciones atribuibles antes de convertir alcance en mandato.

Fuentes

  1. W3C Strategy — asunto 560 de la carta Web Machine Learning
  2. W3C charter-drafts — pull request 829
  3. W3C charter-drafts — commit de alcance WebMCP
  4. W3C — borrador público de la carta Web Machine Learning
  5. Proceso del W3C — contenido de una carta
  6. W3C — carta vigente de Web Machine Learning
  7. WebKit — posición sobre WebMCP
  8. Mozilla — posición sobre WebMCP
  9. WebMCP, asunto 65 — revisión de accesibilidad de APA
  10. W3C Security Interest Group — actas del modelo de amenazas de WebMCP
  11. Web Machine Learning Community Group — informe WebMCP
  12. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption