HR was in the room for every one of those conversations and could not answer them. Not because the people were not good at their jobs, but because nobody had built the thing that would let them. Finance could put a number on its opinions. HR could not.

Twenty years later that is still the gap, and it is now the whole opportunity. A model that can tell you what a decision costs before you commit to it changes what HR is allowed to say in a room. That is what I mean by Business HR, and everything else I write here is a working out of it.

That’s why now is the time to experiment, learn, and build. This moment is an invitation for HR professionals to get hands-on with large language models (LLMs) and experience what they’re capable of. The goal is not to become a developer, but to understand just enough to shape what’s coming.

What we will build together

This is a simple AI assistant that helps people analytics teams get quick, meaningful insights from employee survey comments. It runs entirely on your own machine—no cloud, no API calls—so everything stays private and secure.

You just ask it open-ended questions in plain English, like “What do employees say about recognition in the Sales department?” and it responds with a concise summary based directly on what employees actually wrote in their survey responses.

Behind the scenes, it uses modern AI tools to understand language, organize your data, and generate answers—everything runs locally using Ollama and LLaMA3. The setup takes a few steps, but once it’s running, the experience is smooth and instant. It’s a great way to make open-text feedback accessible and actionable for your team.

This is more than a fun experiment. With AGI just a few years away, now is the moment for HR to get hands-on, build intuition, and lead the way. Jump on the train, or risk being left behind.

Setting up the environment on your computer

Step one is setting up your environment. I’m using Docker to run everything in a contained workspace. Think of Docker as a ready-to-use lab for running software—no setup headaches, no compatibility issues, no messy installs. It lets you run powerful tools like AI assistants in a clean, self-contained environment right on your computer. Everything you need is bundled together: the code, the AI model, and all the technical bits behind the scenes.

For people analytics teams, this means you don’t need to be an engineer to start experimenting with AI. With Docker, you can launch a local assistant that reads your employee survey comments and gives you clear, smart summaries—without touching the cloud or sharing your data. It works the same on every machine, and it keeps things private, simple, and fun.

This setup gives you your own AI sandbox, right on your laptop. It’s a low-risk way to build confidence with generative AI—and with AGI just a few years out, now is the time to start playing and learning.

Next, download Ollama to run the AI model locally. Think of Ollama as a simple, developer-friendly tool that makes large language models (LLMs) like LLaMA3 easy to use on your own machine. It handles all the loading, running, and chatting with the model—no API keys, no cloud latency, and no risk of leaking sensitive data. If ChatGPT runs in the cloud, Ollama is what brings that power directly to your laptop, under your control.

Finally, you’ll need a code editor—something like VS Code works perfectly. It lets you view and modify the scripts if you want, but you won’t need to code anything to get started.

The beauty of this setup is that everything happens locally, it’s fast, private, and fully contained. Just fire it up, ask your questions, and see what your people are really saying.

Once you installed Ollama, run this command. On the Ollama website you can see there are many other LLMs you can use. I’m choosing Llama3

ollama pull llama3

Setting up your project folder and adding the code.

Now that you’ve got your survey data in a CSV file, it’s time to give your AI assistant the structure it needs to run. Think of this step like setting up the workspace: folders, files, and logic that will bring your data and questions to life.

Start by creating a folder on your computer—call it something like survey-ai. Inside this folder, you’ll add:

• Your survey CSV file (for example, survey_data.csv)
• A few Python scripts that do the heavy lifting
• A Dockerfile to build the container
• A requirements.txt file that lists the Python libraries your assistant needs

Here’s what the folder structure will look like:

datadirk-survey-ai/
├── ask_survey_agent.py
├── index_survey.py
├── survey_data.csv
├── requirements.txt
├── Dockerfile

Let’s quickly walk through what each of the scripts does:

• index_survey.py: reads your survey responses, splits them into chunks, generates vector embeddings, and stores them in a local ChromaDB database.
• ask_survey_agent.py: takes your question, finds the most relevant survey chunks, builds a context prompt, and asks LLaMA3 (via Ollama) to generate an answer.
• Dockerfile: defines the environment—Python version, dependencies, and where your code lives.
• requirements.txt: lists the Python packages your assistant depends on (chromadb, sentence-transformers, pandas, etc.).

Here you can find the bare minimum code for each file:

index_survey.py

import pandas as pd
from sentence_transformers import SentenceTransformer

import chromadb
chroma_client = chromadb.PersistentClient(path="./survey_db")

# Load survey
df = pd.read_csv("survey_data.csv")

# Prepare chunks
chunks = []
for _, row in df.iterrows():
    if pd.notna(row.get("question")):
        chunks.append(f"{row['department']} department: '{row['question']}' - Response: {row.get('response', 'N/A')}, Score: {row.get('score', 'N/A')}")
    if pd.notna(row.get("comment")):
        chunks.append(f"{row['department']} department: Comment: {row['comment']}")

# Embed
model = SentenceTransformer('all-MiniLM-L6-v2')
collection = chroma_client.get_or_create_collection(name="survey_chunks")
collection.delete(ids=[str(i) for i in range(len(chunks))])

for i, chunk in enumerate(chunks):
    vector = model.encode(chunk).tolist()
    collection.add(documents=[chunk], embeddings=[vector], ids=[str(i)])

print("Your survey data has been indexed.")

ask_survey_agent.py

import requests
from sentence_transformers import SentenceTransformer
import chromadb
from utils import stream_to_text, summarize_with_llama

# Connect to Chroma and model
chroma_client = chromadb.PersistentClient(path="./survey_db")
model = SentenceTransformer('all-MiniLM-L6-v2')
collection = chroma_client.get_or_create_collection(name="survey_chunks")

# Ask a question
question = input("Ask a question about the survey: ")
query_vec = model.encode(question).tolist()
results = collection.query(query_embeddings=[query_vec], n_results=3)
context = "\n".join(results["documents"][0])

# Build prompt
prompt = f"""
You are an expert HR analyst helping interpret employee survey data.

Use the following context to answer the question.

Context:
{context}

Question:
{question}

Answer:
""" 

# Call Ollama
response = requests.post(
    "http://host.docker.internal:11434/api/chat",
    json={"model": "llama3.2:latest", "messages": [{"role": "user", "content": prompt}]},
    stream=True
)

if response.status_code != 200:
    print("Error from Ollama:", response.text)
    exit(1)

content = stream_to_text(response)
print("\nAI Answer:\n", content)

with open("qa_log.txt", "a") as log:
    log.write(f"Q: {question}\nA: {content}\n{'-'*40}\n")

summarize_with_llama()

Dockerfile

FROM python:3.10-slim

RUN apt-get update && apt-get install -y \
    git build-essential && rm -rf /var/lib/apt/lists/*

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD ["python3", "ask_survey_agent.py"]

requirements.txt

# Core dependencies
pandas==2.2.2
chromadb==0.4.22
sentence-transformers==2.6.1
requests==2.31.0
numpy<2.0

Once the files are in place, build your Docker image from inside the folder:

docker build -t datadirk-ai .

This will create a clean, self-contained AI assistant on your machine. No extra setup, no dependency issues.

Preparing your data.

The assistant works by reading actual employee survey comments and turning them into something searchable and meaningful using AI. But before it can do that, we need to organize the data in a simple format the assistant understands.

Start with a CSV file—a spreadsheet where each row is a comment from an employee. You can export this directly from your existing survey platform. All you need is a column with the comment text, and ideally a few extra columns like department, location, or role. That context helps the assistant give more targeted answers later.

Here’s a simple example of what your CSV might look like:

Once your file is ready, the AI assistant will read each comment, break it into smaller, meaningful chunks, and turn those chunks into numeric “embeddings”, basically, smart fingerprints that help the AI understand what the text means, not just what it says. This is done using a language model called sentence-transformers. It’s part of the behind-the-scenes magic that lets the system respond to your questions with context-aware insights.

To store all this efficiently, we use a tool called ChromaDB. It’s a local vector database that remembers all those embeddings. Think of it as a smart filing cabinet for everything your people said, one the AI can search instantly, by meaning.

The best part? Everything stays on your machine. No cloud upload, no third-party processing. You get fast, private access to your data. And full control over how it’s used.

Launching your local AI assistant.

Now that your data is structured and prepped, it’s time to bring your assistant to life. This part wires everything together so you can start asking natural-language questions and getting real answers—directly from your survey data.

You’ll run a short script that does three things:

1. It loads your CSV file and turns each comment into a vector using sentence-transformers. These vectors capture the meaning of the text.
2. It stores those vectors into ChromaDB, your local search engine that can instantly find the most relevant comments based on the question you ask.
3. It waits for your question, finds the most relevant pieces of context, and sends it to LLaMA3, running locally through Ollama, to generate a smart, human-style answer.

To make this happen, we use Python scripts and Docker. Everything you need is already bundled inside the Docker container, so you don’t have to install or configure anything manually.

Here’s what you run to start indexing your data:

docker run -it --network=host datadirk-ai python3 index_survey.py

Once that’s done, start the assistant like this:

docker run -it --network=host datadirk-ai

It will ask you to type a question like: What do employees say about recognition in the Sales department?

And it will respond with a synthesized answer based directly on what employees actually said. No keywords, no filtering—just meaning, summarized for you in natural language.

This is where things get exciting. Suddenly, open-text comments become something you can use. You can dig into themes, compare departments, spot blind spots—and do it all in seconds, without waiting for an analyst or writing a single formula.

That is a strange position for HR to be in. Measuring whether a capability improved is the one thing HR is supposed to be good at.

The 4D framework

Anthropic built a framework for this with Rick Dakan and Joseph Feller. They call it the 4D. It treats working with AI as a learnable skill set with four parts, and it comes with an assessment, so you can find out where people actually sit.

Read the four out loud to a room and watch what happens. Almost everybody assumes AI skill means prompting. Only one of the four is prompting.

Delegation

Deciding what to hand to AI, and what to keep.

This is the one people skip, and it is the one that separates someone useful from someone who has simply been given a tool. It asks two questions at once. Is this task a good fit for a model at all, and am I the right person to be deciding that?

In HR the cost of getting this wrong is high in a specific way. Handing a model a drafting job is fine. Handing it a decision about an individual, or a piece of work where the input is personal data that should not be leaving your building, is a different matter, and no amount of skill at the other three dimensions rescues you.

Good delegation also means knowing when to do the work yourself because the thinking is the point. Some tasks exist so that the person doing them understands the problem afterwards.

Description

Telling it what you want, and how you want it worked.

This is prompting, and it is the part everyone means when they say AI skills. It matters. Being able to say what good looks like, supply the right context, set constraints, give an example, and ask for the working rather than only the answer makes a large difference to what you get back.

It is also the most teachable of the four, which is why training goes here. A day of practice moves people a long way. That is worth doing, and it is worth being honest that you have then improved one quarter of the thing.

Discernment

Judging what came back.

This is where most of the risk lives. A model produces something fluent every time, whether or not it is right, and fluency is persuasive. Discernment is the habit of asking what would have to be true for this to be correct, spotting the number that is confidently wrong, noticing the citation that does not exist, and recognising the answer that is plausible because it is average rather than because it fits your situation.

People with deep domain knowledge are usually good at this immediately, in their own domain, and poor at it everywhere else. That is worth remembering when you decide who to put in front of a model and on what.

I find this the hardest of the four to raise through training, because it is mostly expertise wearing a different hat. What does help is making people show their checking, out loud, in front of each other.

Diligence

Owning the result: responsibility, transparency, accountability.

Whoever put the work out is answerable for it. That means being open about what was AI assisted, keeping enough of a trail that a decision can be explained later, and not treating a model’s involvement as a reason the answer was somebody else’s fault.

For HR this is the dimension with a compliance edge. If a model touched a process that affects people’s pay, progression or employment, you will at some point be asked to explain how. Diligence is having an answer ready before you are asked.

What to do with the score

An assessment gives you a number per person across four dimensions. That number on its own is mildly interesting and easy to over-read.

It gets interesting the moment you connect it to everything else you already know about your workforce, which is exactly the kind of joining HR should be able to do. Four questions I would ask first:

Every one of those needs the fluency score joined to turnover, reward, performance, position criticality and hiring. None of them are answerable from the assessment alone.

How I would run it

Baseline this month, before any more training. Take the assessment across a population you care about, and record where people start, because a year from now the only honest way to say whether it worked is to compare.

Then measure again in six months. Split the result by the four dimensions rather than reporting one blended number, because the shape tells you what to do next. A team that scores well on description and badly on discernment needs something completely different from a team with the opposite shape.

And expect the leadership scores to be the awkward part. Fluency is cultural, and culture follows what leaders actually do rather than what they announce. If the executive team has signed the budget and delegated the whole thing, that shows up in the numbers, and it is the most useful thing the assessment will tell you.

Physicists have had these for a century

A world model is a model of how a system behaves. You give it a state and you give it a force, and it tells you what happens next.

Gravitation is the easy example. A model of gravitation does not describe the solar system. It simulates it. Give it the masses and the velocities and it will tell you where the planets are in fifty years. Nobody had to observe those fifty years first. The same idea runs fluid dynamics, where you give it pressure and geometry and it tells you where turbulence forms, and climate models, where you give it the forcings and it tells you what the system does over decades.

This is old and well understood. The interesting part is how small the leap is to an organisation.

An organisation is a system too. It has a state: who is where, doing what, under whom, for how long, paid how much. It has forces acting on it: pay, managers, promotion, workload, the labour market outside. If you can describe the state and you know how the forces behave, you can simulate what happens next.

How this differs from predictive analytics

This is the question I get asked most, and it is a fair one, because on the surface both of them produce a number about the future.

Predictive analytics looks at what happened before and finds a pattern in it. It learns that people who have been in the same role for four years, whose manager scores badly, who have not had a raise recently, tend to leave. Then it scores your current people against that pattern and hands you a list. This is useful. I have built plenty of it and I am not going to talk anyone out of it.

The limit is what it can answer. A prediction tells you where you are heading if everything carries on as it is. Ask it what happens if you change something and it has nothing to say, because the change you are considering has not happened yet, so there is no pattern of it to learn from.

A world model is built the other way round. Instead of learning who leaves, it learns what moves leaving. How much a manager change moves it. How much a pay increase moves it, at which levels, and how long the effect lasts. Once you have that, you can set a state, apply a force that has never been applied before, and watch the organisation respond.

Both are worth having. They answer different questions and the second question is the one an executive actually asks.

What this looks like in HR

Take a decision you make every year. Someone proposes a three percent increase to base pay. Finance wants to know what it costs. Everyone in the room already knows the answer to that, because it is arithmetic.

Nobody in the room can answer the second question, which is what it buys. Some of that money comes back. Fewer people leave, so you spend less on recruitment and less on the months a seat sits empty. Absence moves. Productivity moves a little. The effect does not arrive on the same clock as the cost either, because the cost lands in month one and in full, while the return builds over a year.

A world model can walk that month by month and give you the net. The useful number is what the increase costs once the organisation has responded to it. The gross figure is only where the conversation starts.

The same shape covers most of the decisions HR is asked about. What a reorganisation costs in attrition eighteen months out. Whether filling senior seats from outside instead of promoting internally quietly jams the organisation and how long that takes to show. What a richer benefits package returns, priced in retention rather than in premium.

What it takes

A world model needs three things, and the first two are the reason so few organisations have one.

It needs connected data, joined at the person, so that the pay system and the performance system and the absence system are describing the same human being. It needs managed definitions, so that headcount means one thing across the whole model. Then it needs the relationships themselves, learned from your organisation rather than from a benchmark, and kept current, because a relationship measured three years ago in a different labour market is not reliable now.

None of that is exciting and all of it is the work. The model on top is comparatively straightforward once the layers underneath hold.

Why now

Two things changed. Enough HR data is now in one place often enough that learning real relationships from it is possible. And the language models everyone is talking about turn out to be the wrong tool for this, which has made the gap easier to see. A language model predicts the next word from everything ever written. It has never read your reorganisation, your pay round, or this morning’s vacancy list, and it never will, because that information arrives after the model is sealed.

What HR needs is a model of the next action inside one specific organisation, learned from that organisation, still true this quarter. That is a different thing, and physicists have known how to build it for a hundred years.