Decidir qué puede hacer el chatbot y dónde debe parar
La autonomía se concreta en tareas y condiciones. Un mismo chatbot puede ofrecer información de consulta y, en otro contexto, proponer una actuación con efectos importantes. La supervisión debe responder a esa diferencia.
Objetivo: describir las tareas de USO-003 y justificar sus límites, el momento de revisión y la actuación prevista cuando no se cumplen las condiciones de uso.
Mirar la tarea antes que la herramienta
Decir «utilizamos un chatbot» aporta poca información para decidir cómo supervisarlo. Necesitamos saber qué recibe, qué produce, quién utiliza el resultado y qué puede ocurrir después. Tampoco debemos atribuirle capacidades por el nombre comercial: que redacte una propuesta no demuestra que pueda ejecutarla.
Un servicio puede distinguir cuatro tareas:
| Tarea | Resultado que produce | Pregunta de supervisión |
|---|---|---|
| Informar | Describe un procedimiento o una vía de atención | ¿La fuente es vigente y adecuada al contexto? |
| Recomendar | Propone una actuación | ¿Qué efectos tendría seguirla y qué condiciones exige? |
| Preparar una propuesta | Redacta un borrador para una persona | ¿Quién contrasta y autoriza el contenido antes de utilizarlo? |
| Ejecutar | Cambia un estado mediante una integración | ¿Existe esa capacidad y quién autoriza y controla la acción? |
Esta distinción es didáctica. No constituye una clasificación legal ni una escala impuesta por ISO/IEC 42001. Sirve para describir el uso concreto y conectar sus consecuencias con las decisiones de gestión.
Relacionar autonomía, consecuencias y contexto
Para cada tarea pregunta qué puede cambiar para la persona afectada y para el servicio. Un enlace incorrecto puede generar una molestia; una instrucción de configuración inadecuada puede interrumpir el trabajo o modificar una protección. La importancia depende del entorno, del alcance, de la dependencia del usuario y de la posibilidad de corregir el efecto.
La reversibilidad necesita una explicación. Que una configuración tenga una opción de retorno no demuestra que el usuario pueda recuperarse sin ayuda ni que se reviertan todas las consecuencias. Identifica quién podría restaurarla, qué necesitaría y qué información falta.
Relaciona estas preguntas con el registro de riesgos e impactos ya trabajado. Evita valorar todo de nuevo con una etiqueta genérica. Si una propuesta afecta a un escenario existente, conserva su relación; si descubres un escenario distinto, documenta que necesita evaluación.
Elegir cuándo se revisa
La intervención puede producirse antes de que se utilice una respuesta, durante la interacción o mediante una comprobación posterior. También pueden combinarse varias modalidades.
La revisión previa resulta pertinente cuando hemos decidido que una propuesta necesita autorización antes de producir efectos. La supervisión durante la interacción permite reconocer una señal y actuar en ese momento. La revisión posterior ayuda a comprobar resultados y detectar problemas que no se identificaron antes. Esta última no evita un daño que ya se ha producido.
Un muestreo puede aportar información sobre un conjunto definido de respuestas. Debe explicarse qué se selecciona y qué queda fuera. No sustituye una revisión previa que se haya establecido para un caso sensible, ni permite declarar que todas las respuestas no revisadas son correctas.
La elección debe ser coherente con los riesgos y con los recursos del servicio. No imponemos que una persona valide cada frase del chatbot. Sí exigimos que las reglas del ejercicio permitan reconocer cuándo la intervención es necesaria y cómo se realiza.
Expresar límites que se puedan aplicar
«El chatbot solo hará cosas seguras» no permite decidir. Un límite útil identifica la tarea, las condiciones comprobables, la conducta cuando faltan y la función que puede reconsiderarlo.
Por ejemplo, en el diseño didáctico de Tech Server IIT Spain se propone que el chatbot informe sobre la vía de apertura de incidencias si dispone de una fuente vigente y aplicable. Si no puede confirmar ese respaldo, debe ofrecer el cauce de soporte aprobado en lugar de presentar una ruta dudosa como verificada.
Para una recomendación que modifica una configuración, la propuesta podría requerir comprobar entorno, procedimiento y autorización antes de aplicarse. Si falta esa información, la recomendación permanece pendiente de revisión. No se convierte en autorizada porque el supervisor esté ocupado.
Una acción sobre permisos se mantiene fuera del uso propuesto mientras no se haya establecido y autorizado ese alcance. Esto no significa que la tecnología sea incapaz de realizarla; significa que el diseño del caso no acredita permiso para hacerlo.
Aplicación a Tech Server IIT Spain
Supongamos que USO-003 propone seguir PROC-SOP-001. En FD-001 existe información que debe consultarse sobre su versión y ámbito. La tarea del revisor es comprobar qué puede establecerse con esa información y qué continúa pendiente.
La existencia de una cita no acredita por sí sola que el documento se haya recuperado correctamente, que esté vigente o que cubra el entorno del usuario. Si esos extremos no están confirmados, no se presenta la recomendación como contrastada. Se solicita la aclaración necesaria o se conduce el caso a soporte.
Esta decisión no bloquea todas las consultas del chatbot. Delimita la respuesta o función que carece de condiciones suficientes y mantiene una alternativa de atención. Una restricción más amplia necesitaría justificación y una función responsable de decidirla.
Actividad: completar los límites de SUP-001
Describe cuatro tareas propuestas: informar sobre apertura de incidencias, explicar un procedimiento, redactar una respuesta para soporte y actuar sobre un permiso. La última se incluye para comprobar el límite, sin dar por existente una integración de ejecución.
Para cada tarea anota: finalidad; destinatario; resultado y posibles efectos; condiciones; modalidad de supervisión; función que puede intervenir; conducta si falta información; alternativa de atención. Marca las capacidades y los permisos sin confirmar como pendientes.
Orientación para revisar tu propuesta
Qué:
la información sobre apertura de incidencias necesita una vía aprobada y actual. Explicar un procedimiento requiere comprobar su ámbito y distinguir explicación de autorización para ejecutarlo. El borrador para soporte debe tener una revisión definida antes de su uso cuando así lo exija el escenario. La actuación sobre permisos queda fuera de la propuesta mientras no exista un alcance autorizado y evaluado.
No hay una única respuesta para cualquier organización. Tu propuesta será defendible si relaciona las condiciones con sus efectos, evita atribuir capacidades no confirmadas y permite atender al usuario cuando una tarea necesita intervención.
Por qué: Los efectos dependen de la tarea y del contexto, y la ausencia de revisión no elimina una comprobación necesaria.
Cómo: Contrasta tarea, efectos, fuente y condiciones; fija quién revisa y qué alternativa mantiene la atención.
Cuándo: Antes de proponer el uso y cuando cambien tareas o consecuencias.
Dónde: En SUP-001, enlazado con USO-003 y FD-001.
Con qué: Con inventario, criterios, fuentes pertinentes y una propuesta de prueba de la modalidad.
Comprueba tu criterio
¿Puede un chatbot tener autonomía distinta según la tarea?
Qué:
Sí. Puede informar dentro de un ámbito delimitado y necesitar revisión previa para una propuesta que produce otros efectos. Debemos documentar la diferencia.
Por qué: Los efectos dependen de la tarea y del contexto, y la ausencia de revisión no elimina una comprobación necesaria.
Cómo: Contrasta tarea, efectos, fuente y condiciones; fija quién revisa y qué alternativa mantiene la atención.
Cuándo: Antes de proponer el uso y cuando cambien tareas o consecuencias.
Dónde: En SUP-001, enlazado con USO-003 y FD-001.
Con qué: Con inventario, criterios, fuentes pertinentes y una propuesta de prueba de la modalidad.
¿Una revisión posterior evita todos los efectos de una respuesta errónea?
Qué:
No. Puede descubrirlos y ayudar a corregirlos. La decisión de revisar antes, durante o después depende del escenario y debe considerar cuándo se producen los efectos.
Por qué: Los efectos dependen de la tarea y del contexto, y la ausencia de revisión no elimina una comprobación necesaria.
Cómo: Contrasta tarea, efectos, fuente y condiciones; fija quién revisa y qué alternativa mantiene la atención.
Cuándo: Antes de proponer el uso y cuando cambien tareas o consecuencias.
Dónde: En SUP-001, enlazado con USO-003 y FD-001.
Con qué: Con inventario, criterios, fuentes pertinentes y una propuesta de prueba de la modalidad.
¿La falta de un supervisor permite aceptar la propuesta automáticamente?
Qué:
No cuando la regla exige esa revisión. Se utiliza la cobertura o alternativa prevista y se mantiene pendiente la actuación que necesita autorización.
Por qué: Los efectos dependen de la tarea y del contexto, y la ausencia de revisión no elimina una comprobación necesaria.
Cómo: Contrasta tarea, efectos, fuente y condiciones; fija quién revisa y qué alternativa mantiene la atención.
Cuándo: Antes de proponer el uso y cuando cambien tareas o consecuencias.
Dónde: En SUP-001, enlazado con USO-003 y FD-001.
Con qué: Con inventario, criterios, fuentes pertinentes y una propuesta de prueba de la modalidad.
Lo que te llevas: SUP-001 comienza con tareas, condiciones y límites comprensibles. En la lección 8.2 comprobarás si las personas que deben aplicarlos disponen de medios reales.