Cómo las grandes empresas japonesas adoptan herramientas de IA para programar

“A los ingenieros les encanta. Ahora tiene que pasar por seguridad.” Si vendes herramientas de IA para desarrolladores a grandes empresas en Japón, vas a escuchar alguna versión de esa frase muy pronto, y ahí es donde se va la mayor parte del calendario.

Trabajo con clientes enterprise japoneses en Vercel desde 2021: primero como la primera persona de customer success de la empresa que hablaba japonés, y hoy a cargo del go-to-market en Japón como country manager interino. Cada vez más de ese trabajo tiene que ver con v0, el generador de apps con IA de Vercel. El orden en que pasan las cosas se repite lo suficiente como para escribirlo, así que aquí está, con los checklists que me gustaría que ambas partes tuvieran desde el primer día.

Primero viene la curiosidad, y es la parte fácil

La adopción casi nunca empieza con una decisión de compra. Un ingeniero prueba la herramienta con su cuenta personal, o un directivo ve una demo en un evento, y un equipo pregunta si puede usarla en el trabajo. Nadie necesita que lo convenzan de que sirve obtener una pantalla funcionando a partir de un prompt en lenguaje natural.

Después, el pedido llega al departamento de sistemas (情シス) o al equipo de seguridad, y te mandan un cuestionario de seguridad (セキュリティチェックシート), casi siempre un Excel que en una empresa grande puede tener unos cuantos cientos de filas. Ahí es donde se traban la mayoría de los pilotos, y casi siempre por un motivo aburrido: las respuestas existen, pero no en japonés ni con el formato del cuestionario.

La revisión de seguridad

Las filas cambian de una empresa a otra, pero hay cinco temas que lo deciden todo. Si eres el proveedor, ten respuestas escritas en japonés antes de la primera demo, con un enlace a la política que respalda cada una. Si eres el comprador, pide exactamente esto:

• Retención de datos. ¿Cuánto tiempo se guardan los prompts, los archivos subidos y el código generado? ¿Un administrador puede borrarlos? ¿Qué pasa con ellos cuando termina el contrato?
• Entrenamiento. ¿Se usan las entradas o las salidas del cliente para entrenar modelos, ya sea el proveedor o la empresa del modelo que hay detrás? ¿Está desactivado por defecto o hay que pedirlo (opt-out)? ¿Cambia según el plan?
• Ubicación de los datos. ¿Dónde se guardan los datos y dónde se procesan los prompts? Son dos preguntas distintas: la app puede estar alojada en Tokio mientras el modelo corre en otro país. Pide la lista de subencargados (subprocessors).
• SSO y aprovisionamiento. Inicio de sesión único por SAML con el proveedor de identidad de la empresa e, idealmente, SCIM, para que quien se va pierda el acceso el mismo día.
• Registros de auditoría. Quién creó, compartió o desplegó qué, y cuándo; cuánto tiempo se guardan los registros; si se pueden exportar.

Uno más, si puede haber datos personales en un prompt: la ley japonesa de protección de datos personales (個人情報保護法) tiene reglas para transferirlos a un tercero en el extranjero, y alguien va a preguntar cómo encaja la herramienta. “Depende de tu plan” es una respuesta válida, siempre que también digas en qué plan está el cliente.

Legal quiere los términos en japonés

Seguridad y legal (法務) suelen avanzar en paralelo, y legal lee los términos línea por línea. Los términos solo en inglés de una empresa estadounidense generan las mismas preguntas cada vez:

• ¿Hay una versión en japonés? La mayoría de los proveedores puede ofrecer una traducción de referencia (参考訳), con el texto en inglés como el vinculante. Dilo desde el principio.
• Ley aplicable y tribunal competente. Una jurisdicción estadounidense suele aceptarse al final, pero no rápido.
• De quién es el código generado, y qué pasa si infringe derechos de terceros.
• La cláusula de exclusión de fuerzas antisociales (反社条項), que los contratos japoneses incluyen casi siempre y las plantillas estadounidenses no.
• Pago con factura y transferencia bancaria en yenes (請求書払い), no con tarjeta.

Y después está el presupuesto. Muchas empresas japonesas trabajan con un año fiscal de abril a marzo y prefieren, por mucho, un monto anual fijo. Una suscripción por usuario como v0 es fácil: cuentas a las personas. La facturación por consumo necesita una proyección y límites de gasto acordados de antemano; si no, la primera factura inesperada se convierte en el motivo para dejarlo.

Un equipo piloto con fecha límite, y alguien que lo impulse

Un piloto sin fecha límite es una prueba gratuita que vence en silencio. Los que terminan en adopción tienen un equipo pequeño con un entregable real, una fecha y una persona que reporta los resultados.

Esa persona es tu champion interno, y en una empresa japonesa buena parte de su trabajo es nemawashi (根回し, hablar con cada involucrado antes de la decisión formal). Cuando sale el ringi (稟議, el documento de aprobación que circula para que cada responsable lo apruebe), quienes lo firman ya deberían haber oído hablar del piloto por alguien de confianza. Esa parte no la puede hacer el proveedor. Lo que sí puede hacer es mantener al champion abastecido: respuestas en japonés, horarios de consulta y ejemplos que pueda mostrar internamente.

Checklist del piloto:

• Un equipo, un proyecto real, una fecha de cierre.
• Al menos una persona que no sea de ingeniería: un PM, alguien de diseño, alguien del lado del negocio.
• Un responsable con nombre y apellido del lado del cliente, y otro del lado del proveedor.
• Qué se va a mostrar al final, acordado el primer día.

Los hackatones comprimen meses en un día

Los hackatones parecen eventos de comunidad, y además son la herramienta de adopción más rápida que conozco. Coorganicé el Tokyo AI Hackathon con Anthropic, Raycast y Supabase: más de 150 participantes en 57 equipos construyeron extensiones de Raycast con Claude e integraciones MCP en un solo día.

Una fecha límite y un público enseñan a escribir prompts más rápido que cualquier capacitación, y las demos del final le dan a la adopción lo que necesita: gente que ahora cree en la herramienta y ejemplos que funcionan en el contexto de la propia empresa, listos para ir directo al ringi. Si organizas uno dentro de una empresa, configura las cuentas y el SSO antes del día (nadie debería pasar la primera hora intentando iniciar sesión), elige un tema ligado al trabajo real y consigue que alguien con cargo alto vea las demos.

Prototipar los requerimientos con v0

La definición de requerimientos (要件定義) es donde los proyectos japoneses pasan mucho tiempo, muchas veces con un integrador de sistemas, y muchas veces con personas que aprueban documentos que describen pantallas que nunca vieron. Presenté v0 en un webinar sobre IA y definición de requerimientos organizado por DG Business Technology y ROUTE06, y sigue siendo el caso de uso por el que empezaría.

Construye una versión clicable durante la reunión y deja que el lado del negocio reaccione a una pantalla en lugar de a una hoja de cálculo. Trata el prototipo como una pregunta para los involucrados: pon capturas y un enlace en el documento de requerimientos, y decide pronto si algo del código generado se va a conservar. En una empresa grande, normalmente no, y está bien.

Medir el valor sin números de vanidad

Prompts enviados, líneas generadas y licencias asignadas son fáciles de contar y demuestran muy poco. Las encuestas de “horas ahorradas” autodeclaradas no son mucho mejores. Lo que prefiero poner frente a un directivo:

• El tiempo desde la primera reunión hasta un prototipo clicable, antes y después, en un proyecto real.
• Cambios de requerimientos detectados en la etapa del prototipo y no durante el desarrollo.
• Usuarios activos como porcentaje de las licencias, mes a mes.
• Cuántas personas fuera de ingeniería construyeron o cambiaron algo.
• Lo que el equipo piloto dice que no devolvería.

Un antes y después honesto en un proyecto real vale más que un dashboard lleno de totales.

Escribir prompts en japonés

Deja que la gente escriba los prompts en el idioma en que piensa. Los modelos actuales manejan bien el japonés, y mezclar términos técnicos en inglés es como hablan los ingenieros japoneses de todos modos. Lo que requiere cuidado es el texto que va a leer la gente, así que sé explícito con el idioma, el registro y la tipografía:

社内向けの経費申請フォームを作ってください。
- 画面の文言はすべて日本語、です・ます調で
- 氏名は「姓」「名」とそれぞれのフリガナの4項目
- 金額は円表示、3桁区切り
- 見出しには word-break: auto-phrase を指定

Eso pide un formulario interno de solicitud de gastos: todo el texto en japonés y en registro cortés, el nombre separado en apellido y nombre con la lectura en katakana de cada uno, montos en yenes con separador de miles y saltos de línea por frase en los títulos. Cada línea cubre algo que, si no, el modelo deja librado al azar. (Más sobre esos detalles en este artículo sobre localización.)

Después, que un hablante nativo lea el texto generado. El keigo (el lenguaje honorífico) es fácil de usar un poco mal, y un keigo un poco mal usado es justo lo que hace que una herramienta interna se sienta extranjera.

Si eres el proveedor, manda las respuestas de seguridad en japonés antes de que alguien las pida.