There is a lot of discussion about deploying AI across the enterprise. Most of it starts with the model, the platform or the tool. I start somewhere else: the work.
There is a lot of discussion about deploying AI across the enterprise. Most of it starts with the model, the platform or the tool. I start somewhere else: the work.
What decision are we trying to improve? What information does a person need at that moment? What gets in the way today? And what should the technology do when the situation does not fit the standard process? Those questions matter whether the employee is working at a desk, supporting a customer, writing software or managing a shift.
The work is different across those environments, but the technology challenge is connected. AI creates value when it is grounded in the context of the work and built into the workflow. It does not create value simply because it has been deployed.
That distinction is important for CIOs. At UKG, our own employees are primarily desk-based. My responsibility is not to run frontline operations. But we build technology for organizations whose work includes both corporate and frontline employees, so we have to understand both environments. The CIO’s role is to create the architecture, standards and operating model that allow AI to be useful across them.
The first question should not be, “Where can we add AI?” It should be, “Where would better information or faster execution change the outcome?”
For a desk-based team, that might mean reducing the time required to find the answer to a customer question, helping an engineer understand a complex codebase or giving a finance leader a clearer view of a business trend. For a frontline manager, it might mean identifying a staffing risk before a shift begins or helping resolve an exception without moving between several systems.
In context
- Topic: Estrategia y Gobierno de TI — Decisiones de portafolio, costo total, gobierno y marcos de referencia.
- Source: CIO
- Published: 14/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Por qué importa
El gobierno de TI casi nunca falla por falta de tecnología: falla por falta de decisiones claras sobre quién decide qué. Una noticia como esta suele ser el síntoma visible de un modelo operativo que ya no aguanta el tamaño de la organización, y esos modelos se cambian antes de que la presión llegue, no después.
Lo leo buscando el costo de coordinación. Toda decisión de tecnología reparte trabajo entre áreas que no se reportan entre sí, y ahí es donde se pierde el retorno. Si nadie definió quién resuelve cuando dos áreas no se ponen de acuerdo, el proyecto ya tiene su fecha de encallamiento puesta.
Lo que suele salir mal
Lo que suele salir mal es la parte que no se conversó con las áreas que van a cargar el trabajo. Se decide arriba, se comunica hacia abajo, y la resistencia no aparece como oposición sino como lentitud. Nadie dice que no; simplemente todo tarda el doble y nadie sabe explicar por qué.
Qué mirar
- Quién queda como dueño de la decisión y con qué presupuesto propio, no prestado.
- Si aparecen métricas de negocio o solo métricas de entrega — costo por transacción manda sobre porcentaje de avance.
- El calendario real de contratos y renovaciones: ahí se ve si el movimiento era estratégico o era vencimiento.
Cómo leo esta entrada
Si esto llegara a mi mesa, lo primero que pediría no es un plan: es el inventario honesto de lo que ya está andando y cuánto cuesta sostenerlo. Casi siempre aparece que el presupuesto de lo nuevo sale de apagar algo viejo que nadie quiere nombrar, y esa conversación es la que define si el proyecto vive.
La noticia original está publicada en otro idioma; acá se cita el extracto tal como lo entrega el medio y el comentario se escribe en español.
Comentarios
Todavía no hay comentarios. El primero puede ser el tuyo.
¿Lo estás viviendo en tu equipo?
Abrí el chat y contame cómo lo están manejando. Me interesa comparar notas.
