Está claro que su empresa necesita acelerar la adopción de la IA. Lo que está menos claro es cómo hacerlo sin que sea una batalla campal. Después de todo, sus mejores empleados no están esperando que usted establezca estándares; ya están utilizando activamente la IA. Sí, sus desarrolladores están introduciendo código en ChatGPT independientemente de cualquier política que pueda estar planeando. Encuestas recientes sugieren que los desarrolladores están adoptando la IA más rápido de lo que sus líderes pueden estandarizarla; esa brecha, no la velocidad del desarrollador, es el riesgo real.
Esto crea lo que Phil Fersht llama una «brecha de velocidad de la IA»: el abismo entre los equipos que adoptan frenéticamente la IA para ganar y el liderazgo central que duda sobre el riesgo de comenzar. ¿Te suena familiar? Se trata nuevamente de “TI en la sombra”, pero esta vez funciona con sus datos.
He escrito sobre los costos ocultos de la expansión tecnológicaya sea por la libertad ilimitada de los desarrolladores que conduce a una infraestructura inmanejable o por la atractivo de la multinube convirtiéndose en un pantano de pesadillas de interoperabilidad y sobrecostos. Cuando cada desarrollador y cada equipo elige su propia nube, su propia base de datoso el suyo propio SaaS herramienta, no se obtiene innovación, sino caos.
Éste puede ser el status quo, pero es una receta para el fracaso. ¿Cuál es la alternativa?
El problema de las plataformas oficiales
La tentación para un equipo de plataforma es ver este caos y reaccionar construyendo una puerta. «¡Detente! Nadie avanza hasta que hayamos construido la plataforma oficial de IA empresarial». Luego pasarán 18 meses evaluando proveedores, estandarizando en un único modelo de lenguaje grande (LLM) y crear un flujo de trabajo prescrito y monolítico.
Buena suerte con eso.
Para cuando lancen esa única plataforma verdadera para gobernarlos a todos, estará irremediablemente obsoleta. Diablos, al ritmo actual de la IA, corre el riesgo de quedar obsoleta antes de su adopción. El modelo que estandarizaron habrá sido superado cinco veces por alternativas más nuevas, más baratas y más potentes. Sus desarrolladores, frustrados desde hace mucho tiempo, se habrán desplazado por completo de la plataforma, utilizando sus tarjetas de crédito personales para acceder a las API más recientes, creando un punto ciego masivo, no seguro y no monitoreado justo en el corazón del negocio.
Intentar construir una puerta única y monolítica para la IA no funcionará. El panorama avanza demasiado rápido. Las necesidades son demasiado diversas. El modelo que destaca resumiendo documentos legales es terrible escribiendo Pitón. No se pueden confiar las proyecciones financieras al modelo que es excelente para los textos de marketing. Incluso dentro de la ingeniería, el modelo que es brillante en refactorización Java es inútil para escribir manifiestos de K8.
El problema, sin embargo, no es el deseo para una plataforma; es el definición de uno.
De plataformas prescritas a productos componibles
Bryan Ross escribió recientemente una excelente publicación sobre «caminos dorados» que capta perfectamente este dilema. (Se basa en otros argumentos anteriores a favor de estos llamados caminos dorados, como este en el blog de Ingeniería de Plataforma.) Sostiene que debemos cambiar nuestro pensamiento de “puertas” a “barandillas”. El problema, según él lo ve, es que los equipos de plataforma a menudo no logran identificar lo que realmente hacen los desarrolladores. necesidad.
Como escribe Ross: «La mayoría de los equipos de plataformas piensan en términos de 'la plataforma': una oferta única y cohesiva que los equipos usan o no. Los desarrolladores piensan en términos de las capacidades que necesitan en este momento para el problema que están resolviendo». Entonces, ¿cómo se equilibran esos intereses en competencia? Su sugerencia: «Pensar en la plataforma como producto significa ofrecer bloques de construcción componibles. La clave para la adopción modular es tratar su plataforma como un producto con API, no como un flujo de trabajo prescrito».
Ross soluciona el problema. ¿Qué hacemos ahora al respecto?
En lugar de pedirle a un comité que elija el modelo, los equipos de plataforma deberían crear un conjunto de servicios o componibles API esa velocidad del desarrollador del canal. En la práctica, todo esto comienza con un estándar de interfaz de facto. Un estándar de facto es la API de estilo OpenAI, ahora compatible con múltiples backends (p. ej., vllm). Esto no significa que bendigas a un solo proveedor; significa que les da a los equipos un contrato común, probablemente encabezado por una puerta de enlace API, para que puedan intercambiar motores sin reescribir su pila.
Esa puerta de entrada es también el lugar perfecto para imponer resultados estructurados como regla. «Solo dame un mensaje de texto» está bien para una demostración, pero no funcionará en producción. Si desea integraciones duraderas, estandarice JSON-salidas restringidas impuestas por el esquema. La mayoría de las pilas modernas admiten esto, y es la diferencia entre una linda demostración y un sistema listo para producción.
Esta misma puerta de enlace se convierte en su plano de control de observabilidad y costos. No inventes un nuevo “registro de IA”; en su lugar utilice algo como el emergente de OpenTelemetry genAI convenciones semánticas para que los avisos, los ID de modelo, los tokens, la latencia y el costo sean rastreables en las mismas herramientas que los ingenieros de confiabilidad del sitio ya ejecutan. Esta visibilidad es precisamente lo que permite mantener barreras de costos efectivas.
La base fundamental de todo esto es la gobernanza del acceso a los datos. Esta es un área en la que debes ser decidido, manteniendo la identidad y los secretos donde ya viven. Exija la recuperación de secretos en tiempo de ejecución (sin claves integradas) y unifique la autorización para su empresa gestión de identidad y acceso. El objetivo es minimizar nuevas superficies de ataque absorbiendo la IA en patrones existentes y reforzados.
Finalmente, permitir salidas del camino dorado pero con obligaciones: registros adicionales, una revisión de seguridad específica y presupuestos más ajustados. Como recomienda Ross, incorpore la anulación en la plataforma, como un indicador de «continuar con justificación». Registre estas excepciones, revíselas semanalmente y utilice esos datos para desarrollar las barreras de seguridad.
Plataforma como producto, no policía
¿Por qué esta postura de “barandillas sobre puertas” funciona tan bien para la IA? Porque el objetivo móvil de la IA hace que la predicción centralizada sea una estrategia perdedora. Los comités no pueden aprobar lo que aún no entienden y, de todos modos, los proveedores cambiarán según su documento de estándares. Las barandillas dejan espacio para aprender haciendo de forma segura. Esto es lo que las empresas inteligentes ya aprendieron de la adopción de la nube: las limitaciones productivas superan al control imaginario.
Como he argumentado, limitar cuidadosamente las opciones permite a los desarrolladores centrarse en la innovación en lugar del código adhesivo que se vuelve necesario después de que los equipos de desarrollo construyen en diversas direcciones. Esto es doblemente cierto con la IA. La carga cognitiva de la selección de modelos, la higiene rápida, los patrones de recuperación y la gestión de costos es alta; El trabajo del equipo de la plataforma es bajarlo.
Los caminos dorados le permiten avanzar a la velocidad de sus mejores desarrolladores y, al mismo tiempo, protegen a la empresa de sus peores sorpresas. Lo más importante es que este enfoque se adapta a su organización donde se encuentra. Las personas que ya están experimentando con IA obtienen una rampa de acceso rápida y segura que no parece un punto de control. Los equipos de la plataforma obtienen el cumplimiento, la visibilidad y los controles de costos que necesitan sin sentirse obstaculizados por el proceso. Y el liderazgo consigue lo único que las empresas anhelan en este momento: una manera de convertir mil experimentos desconectados en un programa coherente, medido y gobernable.
