Connecting AI to people context (with LGPD doubled up)

Here's something worth noticing: the problem is almost never that AI is bad at math. The problem is it's answering off the top of its head, having never opened your people's real data. It's like hiring the best HR consultant on the market, sitting them in your office, and never giving them access to your ATS, your payroll, your termination history. They'll talk a good game and get it badly wrong, because they're guessing. Connecting AI to people context is exactly what takes it out of the generic. Except here, connecting it wrong cuts deeper than in any other area, because it's not leaking a number, it's leaking a person's life.

01The format of people data decides the path

The first thing that changes everything is to stop treating "HR data" as one single thing. There's no single path for connecting AI to your people. What exists is the data's format, and the format dictates the road.

Think with me about three types of information that live in every HR department. There's structured data, which lives in rows and columns: the export from the ATS or from Gupy, the payroll, the time-tracking system. There's the plain-text document: the termination policy, the employee handbook, the CLT and internal rules, the employment contract. And there's the visual report: the climate survey in PDF with a heat map by area, the headcount dashboard with a colored table.

These are three different natures, and each calls for a different tool. Trying to force all three down the same path is mistake number one. The @datasciencebrain study hits exactly this point: the data's format decides the memory architecture, not the other way around.

02Structured data: AI reasons over the schema, it doesn't need vectors

This is where the most common mistake of anyone who just learned RAG lives: thinking ALL data needs to become vector search. It doesn't. And in HR, a good chunk of your information already lives structured, in rows and columns, straight from the payroll system or the ATS.

When the data is a headcount export or a turnover-by-area table, AI gains almost nothing from turning every cell into a meaning coordinate. What it needs is to understand the STRUCTURE: what the columns are, what each one means, the total row count, the sum of each column, the value range. Instead of "searching for similar chunks", it reasons over the schema, over the statistics (average, sum, max, min), and over a sample of a few representative rows.

Think about the practical difference. To answer "which area has the highest turnover", AI doesn't need a fuzzy semantic search. It needs to look at the payroll table, sort the termination column, and read the first row. That's reasoning over structured data, not vector search. It's cheaper in tokens, more precise, and it doesn't carry the risk of the search pulling up the wrong person's history.

The takeaway is direct: before you build a whole RAG for your people data, ask whether the data isn't already structured. If it is, the path is to give AI the schema, the statistics, and a sample, and let it calculate. Fair enough?

03Document and visual report: two paths that don't mix

Now the other two formats, which a lot of people treat the same way and shouldn't.

The text document is the natural territory of RAG, exactly like you saw in the RAG and agent memory lesson (2.4). The termination policy, the employee handbook, the employment contract: all of that is plain text, and AI finds the right answer by searching for meaning. You ask "what's the notice period in this policy" and the meaning search pulls the right passage, even if the policy says "transition period" instead of "notice period". For text, RAG solves it.

The visual report is where the trap lives. Take your climate survey's PDF: it has a heat map by area, a table of eNPS by seniority, numbers aligned in columns, a legend that changes the meaning of the chart next to it. If you feed this PDF into a traditional RAG, it extracts the text and SCRAMBLES everything: the heat map becomes a soup of loose numbers, the table disappears, the relationship between the area and the index gets lost. Traditional RAG breaks on the visual report, and the worst part is it breaks silently: it hands you a number that looks right and is wrong, pointing to the problem in the wrong area.

The way out is to read the page as an IMAGE. Models with vision (multimodal) look at the PDF like a photo of the page, see the table as a table, the heat map as a chart, and preserve the relationship between the area and the index. It's the difference between blindly transcribing a climate survey and actually looking at it.

04Doubled-up security: here it's genuinely personal data

Everything we've seen so far is about getting AI to be right. Now the point that, in HR, can knock you down in a different way than in finance: what leaves the company isn't just a number, it's a person.

The instant you connect AI to your team's data, the security check is DOUBLED UP compared to any other area. It isn't "the company's sensitive data", like a price or a margin. It's data that identifies a specific person: name, national ID, performance review, termination reason. And sometimes it's truly SENSITIVE personal data, as defined in article 11 of LGPD: health, maternity leave, orientation, among others. This type of data calls for a level of care that not even financial data always requires.

There are three layers of protection that go together, and here they're even stricter. The first is anonymization: swap a person's name for a code before sending it to AI, mask the national ID, aggregate by area instead of exposing the individual, whenever the question can be answered in aggregate form. The second is choosing where it runs: sensitive personal data calls for a model running locally or in a closed environment, never the public cloud without anonymizing first. The third is the gateway, the gate that sits between you and the model and BLOCKS what can't pass through, logging everything that did, because in an LGPD audit that log is what proves you handled the data with care.

This gateway is the same concept as the Stack plus AI Gateway you saw in the Machine Room, and it connects directly to the execution-governance lesson (4.4). Here the difference is named after a labor lawsuit, an ANPD fine, and broken trust with your own team. Leaking an employee's sensitive data isn't like leaking a margin number: it's a person's life exposed.

05Putting it all together: from generic data to your people's data

Now you can see the whole picture. Connecting AI to people context is what takes it out of the generic, it's what makes it stop guessing and start answering with your ATS, your payroll, your climate survey right in front of it. But connecting is a double-edged sword that cuts deeper in HR: connect it wrong and it either leaks information that identifies a person, or it invents a finding that looks true about a real person.

The mental sequence that protects you is always the same, with one extra step at the end. First, look at the FORMAT of the data and choose the path: structured becomes reasoning over the schema, text becomes RAG, visual report becomes reading as an image. Second, before you plug anything in, run the doubled-up security check: does this data identify a person, is it sensitive data under article 11, does it need anonymizing, does it run locally or in the cloud, is the gateway in the middle. Format first, security always, and in HR that security is never optional or "case by case".

Whoever understands this order stops treating AI as a magic box that guesses findings about your team and starts treating it as an analyst you give access to, with rules, over what it can see about real people. Fair enough?

Do it now

Practice

</content>

For the board