AI Cities para apps de turismo: doce ciudades ya conectadas, una integración y el producto de viaje que puedes entregar

Desde que AI Cities salió a la luz, la pregunta que me hacen ha cambiado de forma. Antes era "qué es un Connector". Ahora es "¿puedo construir un producto sobre esto?", y quienes preguntan no son gente de plataforma. Dirigen organizaciones de marketing de destino, construyen planificadores de viajes, operan productos de conserjería de hotel, y todos llegan con la misma hoja de cálculo: la lista de APIs que tendrían que integrar para cubrir bien una sola ciudad.

Este post responde con un inventario, una arquitectura y las partes difíciles. La versión corta: el turismo es el dominio donde una ciudad conectada se mapea casi uno a uno sobre un producto de consumo. Un viajero toca seis de los ocho sistemas de una ciudad en las primeras setenta y dos horas, cada uno de esos toques es ya una lectura en vivo, y la integración que habrías escrito para una ciudad es la misma integración para doce.

Por qué el turismo es la primera superficie de producto de una ciudad conectada

En AI Cities una ciudad se organiza en ocho sistemas: movilidad, energía, medio ambiente, servicios públicos, cultura, geografía, comercio y seguridad. Así piensa un gobierno municipal sobre sí mismo. No es así como piensa un visitante, y el hueco entre ambos es donde vive un producto de viaje.

Toma un visitante en Ámsterdam durante tres días. La movilidad es la estación de bicicletas, el tranvía, la zona de estacionamiento que no hallará dos veces. La cultura es qué hay esta noche y si quedan dos entradas. El medio ambiente es la banda de lluvia de las nueve y el aire junto al agua. Los servicios públicos es la dirección, el registro del monumento, el conjunto de datos abierto detrás de ambos. La geografía es la distancia, la elevación, la ruta que evita la cuesta. El comercio es el precio y la tarjeta. La seguridad es la obra vial que cierra la ruta del canal a las seis.

Seis de los ocho sistemas de una ciudad, cruzados el primer día, sin que el visitante llegue nunca a aprender el nombre de un sistema. Ninguna otra categoría de producto toca una ciudad tan amplia y tan rápido.

La segunda razón es la forma de la carga de trabajo. El turismo es lectura pesada y escritura ligera. Un visitante hace mil preguntas y reserva un puñado de cosas, que es la carga ideal para un plano de datos que lee en vivo desde la fuente en el momento de la pregunta y, cuando un Connector puede actuar, actúa sobre un servicio y no sobre la ciudad. Nuestro contrato en la página de AI Cities es explícito: nada aquí da a un agente control sobre la infraestructura pública. Para un producto de viaje eso no es una limitación. Es el contrato correcto.

La tercera razón es aritmética. Cada producto de viaje que he revisado lleva la misma línea oculta: las integraciones. Una ciudad cubierta bien significa transporte público, bicicletas compartidas, estacionamiento, clima, calidad del aire, eventos, venta de entradas, geocodificación y el portal de datos abiertos local, cada uno con su clave, su límite de tasa, su forma de error y su día de cambio. Multiplica eso por las ciudades en las que quieres estar y tienes por qué la mayoría de los productos de viaje se detienen en tres mercados.

El inventario honesto: lo que está realmente conectado

Doce ciudades están en vivo en beta: Ámsterdam, Berlín, Lisboa, Londres, Madrid, Moscú, Nueva York, París, Río de Janeiro, San Francisco, Singapur y Tokio. Cada una se apoya en Connectors hacia sus propios sistemas, no en un feed genérico mundial.

Ámsterdam es la más completa, así que la citaré con precisión: ocho sistemas en vivo hoy con 40 Connectors. En movilidad, CityBikes para el alquiler de bicis en vivo, TomTom Parking Availability, Google Maps, Mapbox, Uber y el conjunto de datos propio de zonas de estacionamiento y tráfico de la ciudad, sin clave. En cultura está el archivo del Rijksmuseum, Eventbrite, Ticketmaster, Bandsintown y el registro de eventos, recintos y deporte de la ciudad. En medio ambiente y seguridad están AccuWeather, AirVisual, AQICN, OpenWeather, Open-Meteo, el feed de incidencias de la ciudad para cortes y obras viales, y pronósticos de inundaciones del Global Flood Awareness System. En servicios públicos está el explorador de datos abiertos del DSO con más de 122 conjuntos de datos, el registro de direcciones BAG, los calendarios de residuos y reciclaje y el portal de datos abiertos de la UE.

Relee esa lista, porque la mezcla es el punto. Aproximadamente la mitad son APIs comerciales con una cuenta detrás. Aproximadamente la mitad son registros de la ciudad, accesibles sin ninguna clave de API. Un producto de viaje necesita ambos: los feeds comerciales dan cobertura y calidad, los feeds municipales dan los datos que solo una ciudad conoce, como qué muelle está cerrado o qué árbol cayó en la tormenta.

Dos reglas vienen con ese inventario, y exigiría a cualquier equipo cumplirlas. La primera: la página de la ciudad indica qué sistemas están conectados hoy y cuáles se siguen conectando, para que te comprometas con funciones sobre lo que existe y no sobre una hoja de ruta. La segunda: todo en esa página es una lectura en vivo en el momento en que preguntas. Nada está pre-caché, así que tu producto no puede publicar un horario obsoleto y culpar a la plataforma por ello.

Esto no es una API de viajes más

El turismo lleva décadas con APIs. El mundo de Amadeus y Duffel, el linaje de los GDS, resuelve inventario: asientos, tarifas, reservas, cambios. Es excelente en la transacción y no sabe nada del lugar. Esas APIs pueden decirte qué vuelo aterriza a las 14:00. No pueden decirte que la carretera al hotel cierra a las seis, que el AQI a lo largo del corredor está subiendo, o que el único concierto de esta noche está a tres paradas.

La capa urbana responde a ese segundo conjunto de preguntas, y las dos son complementos, no competidores. Un producto que tiene la tarifa pero no la calle es un motor de reservas. Un producto que tiene la calle pero no la tarifa es una guía. El producto interesante tiene ambas cosas, y hasta ahora tener ambas significaba mantener dos programas de integración con dos curvas de mantenimiento distintas.

Ese es el cambio real. Las APIs de transacción iban a ser siempre una mercancía que alquilas. El lado de la ciudad nunca estuvo disponible como mercancía en absoluto: integrabas un municipio, o no tenías los datos. AI Cities hace que el lado de la ciudad sea alquilable de la misma manera, con el mismo patrón de llamada, para cada ciudad que esté conectada.

La arquitectura: una integración, doce ciudades

Por debajo, cada Connector se expone sobre MCP, el protocolo abierto que hablan los asistentes que ya usas. Tu aplicación se identifica con un par de claves que creas una vez en el panel: un app id público y una clave secreta de aplicación. Te diriges a tus viajeros por el id que ya les asignas, y para cada uno el SDK devuelve un handle con alcance sobre los sistemas de la ciudad que había conectado. Vinkius aprovisiona la conexión, retiene las credenciales y ejecuta detrás de un plano de datos gobernado. Tu código no lleva ninguna clave upstream, ningún flujo OAuth, ningún bucle de reintentos por ciudad.

La unidad de alcance es el viajero, no el inquilino, y esta es la decisión de diseño que defendería con más fuerza en un producto de viaje. Una conserjería que puede cambiar la reserva de alguien solo es segura cuando la reserva que toca pertenece a quien pregunta. Los Connectors de cada viajero son conexiones aisladas con sus propios tokens, enumeradas y ejecutadas dentro de su propio runtime, medidas por separado y detenidas por separado. El aislamiento lo impone la forma de la ruta de datos, no un documento de políticas.

Este es el bucle, tal cual del ejemplo del SDK, con los sistemas de la ciudad del viajero como conjunto de herramientas:

import OpenAI from 'openai';
import { Vinkius } from '@vinkius/connect';
import { toOpenAITools, runOpenAIToolCall } from '@vinkius/connect/openai';

const openai = new OpenAI();
const MODEL = process.env.OPENAI_MODEL ?? 'your-model-id';

const vinkius = new Vinkius({
  appId: process.env.VINKIUS_APP_ID!,
  apiKey: process.env.VINKIUS_APP_KEY!,
});

export async function concierge(userId: string, question: string) {
  const caps = await vinkius.user(userId).capabilities();
  if (caps.length === 0) {
    return 'Connect a city first and I can answer that live.';
  }

  const tools = toOpenAITools(caps);
  const messages = [{ role: 'user', content: question }];

  for (let step = 0; step < 4; step++) {
    const reply = await openai.chat.completions.create({ model: MODEL, messages, tools });
    const msg = reply.choices[0]?.message;
    if (!msg?.tool_calls?.length) break;

    messages.push(msg);
    for (const call of msg.tool_calls) {
      const result = await runOpenAIToolCall(caps, call, {
        idempotencyKey: `${userId}:${call.id}`,
      });
      const text = result.content.map((c) => c.text).join('\n');
      messages.push({
        role: 'tool',
        tool_call_id: call.id,
        content: result.isError ? `The tool reported an error: ${text}` : text,
      });
    }
  }

  return reply?.choices[0]?.message?.content ?? '';
}

No hay código específico de ciudad en esa función. No sabe que está en Ámsterdam. La ciudad llega a través de las capacidades que el viajero ha conectado, y por eso la misma función sirve doce ciudades y la decimotercera sin una rama.

Ejemplo resuelto: una pregunta, cinco sistemas

"Aterrizamos a las 14:00 con un niño y un carrito. ¿Dónde cenamos esta noche cerca del museo, y cómo llegamos si llueve?"

Traza lo que debe ocurrir antes de que esa respuesta sea honesta:

1. Resuelve el hotel y el museo a coordenadas. Geografía: LocationIQ u OpenCage.
2. Lee la banda de lluvia y la calidad del aire para esa ventana. Medio ambiente: Open-Meteo y AccuWeather, AQICN para el corredor.
3. Lee qué hay esta noche cerca de esa dirección y si quedan dos entradas. Cultura: el conjunto de datos de eventos de la ciudad, Eventbrite, Ticketmaster.
4. Consulta el feed de incidencias para la ruta que ibas a recomendar. Seguridad: el conector propio de estado e incidencias de la ciudad.
5. Elige el desplazamiento: bicis en el anclaje, el tranvía o estacionamiento cerca del recinto. Movilidad: CityBikes, TomTom, Google Maps.

Cinco sistemas, una conversación, y el viajero no instaló nada. Cada paso es una llamada a herramienta que el modelo eligió, cada resultado es una lectura en vivo, y cada llamada queda en la pista de auditoría con el id del viajero. Si el paso cuatro devuelve un muelle cerrado, la respuesta cambia antes de enviarla, no cuando el huésped ya está allí.

Lo que es difícil, dicho con franqueza

La varianza por ciudad es real. Ámsterdam tiene ocho sistemas conectados con 40 Connectors. Otra ciudad de la lista puede estar viva en movilidad y medio ambiente mientras los servicios públicos se siguen conectando. La respuesta de ingeniería es enumerar capacidades en runtime y diseñar para un conjunto que cambia, no codificar una matriz de ciudades en tu configuración. La respuesta para el usuario es honestidad: decir qué hay y dónde.

La frescura es toda la promesa. Un producto de viaje vive o muere según si el tranvía circula de verdad. Las lecturas ocurren en el momento de la pregunta, así que el modo de fallo que diseñas no son datos obsoletos, es que el upstream esté brevemente indisponible. Maneja los fallos de herramienta como resultados, no como excepciones, y deja que el modelo diga con franqueza que no lo sabe ahora en vez de inventar una hora de salida.

Las acciones son estrechas a propósito. Donde un Connector puede actuar, actúa sobre el servicio: mantener una reserva, reservar un sitio. Nunca actúa sobre la infraestructura pública. Construye sobre lecturas y unas pocas escrituras explícitas y nunca encontrarás el límite. Diseña un producto que asume poder reprogramar el transporte de una ciudad y has diseñado algo que no puede salir a producción.

Cada llamada queda registrada. Todo se ejecuta en Vinkius: ejecución V8 aislada por conexión, más de 34 reglas de seguridad, una pista de auditoría firmada de cada acción, límites de gasto que se pausan en vez de sorprender, y un interruptor que detiene a todos los agentes. Para un producto de viaje al consumidor, esta es la diferencia entre "nuestra IA hizo algo raro anoche" y un recibo que nombra herramienta, viajero y marca temporal. El plano de control está cubierto con código en Gobernanza de IA: el plano de control detrás de cada llamada a herramienta de tus agentes, y el propio sandbox en Arranques en cero para código no confiable.

Cuatro productos que puedes lanzar este trimestre

Un concierge de viaje de un día. Chat primero, sin descarga, sin login por servicio. Lluvia a las nueve, bicis en el anclaje de la oficina, dos entradas antes de la cena, el último tren a las 22:50. Cada entrada de esa conversación es una lectura en vivo que ya tienes.

Un router consciente de confort y accesibilidad. El itinerario que evita la cuesta, el corredor de AQI alto, el muelle cerrado y los escalones de la estación. Calidad del aire, elevación, incidencias y cálculo de rutas son Connectors separados, componerlos es el producto, y ninguna app de mapas incumbente lo hace.

Una oficina trasera de destino. Para una organización de marketing de destino o un grupo hotelero: los eventos de hoy, los recintos de esta noche, los datos abiertos y el feed de incidencias, alimentando un sitio o un asistente de mensajería que responde en el idioma del visitante, no una página estática actualizada la primavera pasada.

Una capa urbana para una plataforma de viajes existente. Si ya tienes los usuarios y las reservas, el apalancamiento es distinto: una integración, y cada ciudad que se conecte se convierte en un mercado que puedes abrir sin un nuevo proyecto de integración.

La construcción empieza donde termina el cableado

La demo de AI Cities es preguntar a tu asistente sobre una ciudad y obtener una respuesta en vivo. Eso no es el producto. El producto es lo que construyes sobre los mismos Connectors, para viajeros que nunca sabrán que hubo un protocolo por debajo.

Empieza en el índice de AI Cities, abre la ciudad que te interesa y lee qué sistemas están en vivo hoy. Después conéctala con el AI Connect SDK y construye la app local que debería haber existido.