Toda direção que se lança à IA depara-se, mais tarde ou mais cedo, com esta pergunta: que decisão pode um sistema tomar, e que decisão permanece com uma pessoa. A pergunta parece simples. A resposta muitas vezes não o é, porque a fronteira não está na decisão em si, mas no que a organização organizou em torno dela.
Não existe uma lista fixa de decisões que, por definição, devem permanecer humanas. Uma decisão de demissão, uma rejeição de crédito, uma avaliação médica: são exemplos frequentemente citados, mas a razão pela qual são sensíveis varia de organização para organização. Numa instituição trata-se de responsabilidade jurídica, noutra da irreversibilidade do resultado, numa terceira da ausência de uma margem de erro razoável. Quem copia uma lista de outra organização copia uma resposta sem ter feito a pergunta.
O que funciona é dissecar a própria decisão: qual é o impacto se algo correr mal, o resultado é reversível, e há alguém que possa explicar e justificar o resultado. Essas três perguntas estão na base do que noutro lugar se designa por regras de agente: limites estabelecidos que determinam quando um sistema pode continuar e quando deve parar e envolver uma pessoa.
A tentação é grande de deixar esta questão a cargo do departamento de TI, como se fosse uma configuração que se faz uma vez e está resolvido. Isso não funciona, por uma razão simples: uma regra de agente só é fiável se a organização em torno dela estiver em ordem. Se ninguém souber quem é o responsável por um processo, ninguém pode determinar quem é o ponto de escalonamento. Se os dados não estiverem em ordem, um sistema não sabe quando encontra uma excepção que exige uma pessoa. As dimensões fundamentais de uma organização — governação, infraestrutura, gestão de dados — têm, por isso, prioridade sobre a pergunta de que decisões podem ser automatizadas. Sem essa base, qualquer fronteira que trace é uma fronteira no papel.
Esta é precisamente a razão pela qual esta pergunta raramente vive num único lugar da organização. A direção vê o risco, o CIO vê a viabilidade técnica, o responsável pelo processo vê a prática diária. Como reunir estas três perspetivas antes que o ritmo da automação se torne fonte de desacordo está descrito em como conduzir a conversa sobre o ritmo entre a administração e a direção. Quem só faz esta pergunta quando o primeiro piloto já está em curso, fá-la tarde demais.
A medição de maturidade da hybridresourcing mapeia se uma organização tem a base necessária para traçar este tipo de fronteiras de forma significativa. Sete dimensões, cinco níveis de baseline a intelligence, e uma ronda de plotagem em que várias pessoas pontuam de forma independente. Essa dispersão é muitas vezes a parte mais útil: se um CHRO coloca a maturidade dos dados em activation e o CIO em baseline, o senhor sabe que primeiro precisa de haver uma conversa antes de se estabelecer uma regra no papel que ninguém consegue executar.
O que a medição não faz é dizer que decisão, na sua organização, pode ser automatizada. Ela mede prontidão, não a adequação de uma tarefa específica. Diz-lhe se a organização consegue suportar o que a IA é capaz de fazer, não o que a IA concretamente assumiria. Essa distinção entre suportar e assumir é a diferença entre suportar a IA e deixar a IA assumir, e é uma distinção que esta página mantém deliberadamente: uma pontuação na medição não é um cheque em branco nem uma proibição, é uma fotografia do estado em que a organização se encontra neste momento.
Essa fotografia envelhece. Uma organização que hoje pontua em foundation para a gestão de dados pode, dentro de um ano, estar em activation, ou pode igualmente ter permanecido no mesmo lugar. Com que frequência vale a pena medir novamente, e do que isso depende, pode ler em com que frequência deve repetir-se uma medição de maturidade. Uma medição única que desaparece numa gaveta tem pouco valor; uma medição que reinicia a conversa na direção, tem.
A medição não resolve o desacordo na sua direção. Torna-o visível, e isso não é o mesmo. Se a sua administração e direção já discordam há algum tempo sobre o ritmo de adoção da IA, a causa está muitas vezes mais profunda do que uma falta de factos: trata-se de tolerância ao risco, de quem é responsabilizado por quê, do que acontece quando alguém abre uma janela de chat e pensa que com isso trouxe a IA para dentro de casa. O que o senhor não vê se só conhece a janela de chat é precisamente a parte da organização a que esta pergunta se refere: a infraestrutura, as regras, as pessoas que sabem quando um sistema deve parar. Por que razão a sua direção discorda sobre o ritmo está explicado nesta página, e é muitas vezes mais útil ter essa conversa primeiro do que esperar que um piloto encalhe e a pergunta volte à mesa de qualquer forma.
Esta página trata da fronteira que o senhor traça previamente: que decisão permanece com uma pessoa, independentemente do que um sistema tecnicamente consegue fazer. Uma vez estabelecida essa fronteira, ainda que de forma aproximada, a pergunta desloca-se para o próprio trabalho: que tarefas dentro dessa fronteira são adequadas para transferir, e que parte de uma função permanece trabalho humano independentemente da prontidão organizacional. Essa pergunta a medição de maturidade não responde. O scan de trabalho da FTE TO AI calcula, por tarefa, que parte do trabalho pode ser assumida pela IA, e liga-se assim ao ponto onde esta página termina: não se a sua organização está preparada, mas o que concretamente está pronto para ser transferido quando o estiver.
A ferramenta com que o senhor mesmo pode mapear isto está em construção. Quem quiser fazer a medição assim que estiver disponível pode inscrever-se na lista de espera.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.