Skills Inference Reads Your Work: What TechWolf, Workday and Microsoft Process

Microsoft's skills engine reads the subject lines of your email, the titles of your documents and the transcripts of meetings you attend, then proposes what you are good at. It ignores anything older than 90 days. Skills inference privacy is no longer a theoretical question: the profile is built from your work, and the law treats that profile as personal data about you.

The short answer. Skills inference tools build a profile of what each employee can do by reading HR records and the systems where work happens. Under GDPR that profile is personal data, so employees can see it, correct it and often object to it. In Germany a works council must agree before the tool goes live.

This post is written for the head of people operations or HR systems who owns the rollout. It is the person who will be asked, by legal and by the works council, what the tool reads and who can change the output.

What skills inference actually reads

Skills inference means a model reading records about a person and proposing a list of skills, often with a proficiency level. The output is a profile. The input is the part buyers rarely inspect.

Two kinds of input exist. HR records are the familiar ones: job titles, job history, completed courses, certifications and performance reviews. Work records are the newer ones: tickets, code commits, documents, messages and meetings.

The shift that matters is from the first kind to the second. A job title says what you were hired to do. A ticket history says what you actually did, when, and how often. That is more useful for a skills profile, and it is also exactly the kind of data employment law was written to restrain.

I think most buyers evaluate these tools as a catalogue question, asking how many skills the taxonomy holds. The better first question is a data-flow question: which systems, which fields, and who sees the result before anyone acts on it.

Compiled from public vendor pages accessed October 2026. "Not described publicly" means the public documentation does not say, not that the control is absent. Contract and implementation documents may say more, and you should ask for them.

TechWolf: the widest skills inference data flow

TechWolf is a Belgian company that sells skills inference as infrastructure underneath other HR systems. Its own FAQ states the scope plainly. It connects to three groups of sources: HR and talent systems, systems of work, and learning platforms.

The systems of work it names are Jira, Confluence, GitHub, ServiceNow, Salesforce, Microsoft Teams and Slack. It ingests through APIs where a system supports them and falls back to secure file transfer where it does not. It also says it does not pull from LinkedIn profiles or other public sources, which is a deliberate and sensible line.

What the Workday feed contains

The developer documentation shows the field level, which is rarer than it should be. For Workday customers, data moves as exported Enterprise Interface Builder files. The employee specification asks for learning history, internal and external work history, certifications, education, goals, feedback and performance data.

Two fields deserve a second look. Feedback includes the question and the free-text comment. Performance data includes the manager's overall review comment. Resumes travel as attachments. That is not metadata. It is the most sensitive prose an HR system holds about a person.

TechWolf's own guidance is to filter these feeds, sending only completed courses and goals with a relevant status. That filtering is a customer configuration choice. Whoever builds the export decides how much of each person's file leaves Workday, so that decision belongs in your impact assessment, not in an integration ticket.

Who validates the output

On validation TechWolf is clear. Inferred skills go to the employee by default, through a skill assistant in Teams or Slack. The manager sees what the employee decided, for visibility rather than sign-off. A stricter manager-first route exists as an option.

The Teams assistant records which skills were confirmed or rejected, when, and by whom. Employees can review earlier decisions, add missing skills and optionally rate their own proficiency. On privacy, TechWolf's integration page says it is GDPR-compliant, ISO 27001 certified and SOC 2 Type II attested, minimises personal data and supports pseudonymisation. Those are vendor statements. I did not see the audit reports behind them.

One detail a buyer should notice. The privacy policy on TechWolf's website covers website visitors, applicants and prospects. It does not govern your employees' data, which sits under your processing agreement with the vendor. The questions worth putting into that contract are covered in the clause-by-clause guide to AI data processing agreements.

Workday Skills Cloud: the HR record as the input

Workday's approach starts from the HR system it already runs. In 2022 Workday's general manager for CHRO products told Computerworld that skills data can come from the HR system, online assessments, job profiles, HR transactions such as job moves, resumes, labour market data, onboarding materials, performance reviews and learning systems.

That list is four years old, and the current Skills Cloud page is less specific. It describes cross-checking skills against internal and external sources. It lists a capability called Skills Verification and another called Mass Skills Population, described as bulk-assigning skills to worker and job profiles.

Shared models and the 2018 opt-in

Workday's 2018 launch release said that once customers elected to participate, their contributed data was de-identified and added to an aggregated dataset. That was an opt-in model of pooling. Whether the same terms hold today is not stated on the current product page, and you should ask.

The current Responsible AI page says Workday never shares customer data to train third-party public models. That sentence is about third-party models. It does not answer whether Workday's own models learn from your tenant. Workday also says it publishes AI fact sheets per feature covering inputs, outputs, limitations and privacy, and acts as a processor under standard contractual clauses. Request the fact sheet for Skills Cloud before you sign, not after.

Many Workday customers run TechWolf alongside it. TechWolf's documentation describes pushing inferred skills back into Workday through a skill sync. In that set-up your data-flow map has two inference engines and one destination, and both need to appear in your records of processing. The licensing side of the same relationship is examined in the analysis of Workday Flex Credits as a seat hedge.

Microsoft People Skills: inference inside Microsoft 365

Microsoft is the most transparent of the three about inputs, and the most restrained in scope. Its Learn page says the engine draws on Microsoft Graph signals: user profiles, job titles, collaboration signals and key phrases from emails, meetings and documents. It says it infers only from Microsoft 365 and does not use activity in other business applications.

The user-facing support article is more concrete. It lists titles and summaries of documents, email subject lines, and Teams meeting summaries and transcripts as examples of what the model reads. Meeting transcripts are the item I would put in front of a works council first.

Controls Microsoft documents

Microsoft documents three controls that the other two vendors do not describe publicly. First, AI inferencing is not on by default for commercial users. Tenants with Copilot licences can opt in their E3 and E5 users. Second, an administrator can turn inferencing off for everyone or for a group through Feature Access Management. Third, individual users can opt out in their profile settings.

There are also time limits. The engine refreshes about every 30 days and does not consider activity older than 90 days. Skills an administrator marks as restricted are removed from profiles within 24 hours. Microsoft states that it does not see the data used to identify your skills, and that nothing about that data is visible to other people.

What the documentation does not settle is whether a suggested skill is visible to colleagues before the user confirms it. That gap matters, because a profile shown to a manager before the employee has reviewed it is a different processing activity from a private suggestion. Test it in your own tenant rather than assuming.

Skills inference privacy under GDPR: the duties that already apply

None of the duties in this section waits for the AI Act. GDPR has applied since 2018, and an inferred skill is personal data about an identifiable employee. Article 4(4) defines profiling as automated processing to evaluate personal aspects of a person. A model proposing what someone is good at fits that definition comfortably.

Lawful basis: consent rarely works at work

The UK Information Commissioner's guidance on monitoring workers states the problem directly. It says consent is not usually appropriate in the employment context, because of the imbalance of power. Most employers will rely on legitimate interests instead, which brings a balancing test and a right to object.

The ICO also says employers increasingly use analytics to infer worker performance, and that monitoring should not happen "just in case". The same guidance lists performance management among the examples of processing likely to need a data protection impact assessment. Its broader position on where monitoring stops being lawful is laid out in the breakdown of where employee monitoring crosses the legal line.

Article references are to the published texts. Member states may add more specific employment rules under GDPR Article 88, so local law can be stricter than this table.

Rectification is the right vendors under-design for

Article 16 gives a person the right to have inaccurate data corrected and incomplete data completed, including by a supplementary statement. For a skills profile, that means an employee who disagrees with an inferred skill, or with a proficiency rating, has a statutory route to fix it.

A confirm-or-reject button handles the first case. It does not handle the second, where the person wants to say the profile is missing what they actually do. TechWolf's add-a-missing-skill function gets closer. My view is that every buyer should test this flow by hand before rollout, using a real employee who thinks the profile is wrong.

Works councils and skills inference: Germany as the strict case

If you employ people in Germany, the works council is the gate that actually stops projects. Section 87(1) no. 6 of the Works Constitution Act gives it co-determination over the introduction and use of technical devices designed to monitor the behaviour or performance of the employees. Without agreement, the conciliation committee decides.

Vendors describe skills inference as career development. The statute asks a different question: whether the device can be used to watch behaviour or performance. A tool that reads ticket histories and manager review comments to rate proficiency is hard to describe as anything else. I would assume co-determination applies and negotiate from there.

The AI-specific provisions most teams miss

Germany amended the Act with AI in mind. Section 90 requires the employer to inform the works council in good time about working procedures that include artificial intelligence. Section 80(3) says that where the council must assess AI, calling on an outside expert is deemed necessary, which means the employer pays for that expert.

Section 94 requires council approval for general assessment criteria, and section 95 covers selection guidelines for transfers and regrading. Section 95(2a) extends that to guidelines drafted with AI. If inferred skills feed internal mobility, those sections are in play as well.

The practical answer is a works agreement that names the data sources, the fields excluded, who sees unconfirmed suggestions, and a ban on using the profile for performance ratings. Germany is the strict case, but works councils in other EU states ask similar questions. How assessment criteria change once AI is involved is covered in the analysis of performance review criteria in the AI era.

The EU AI Act: when a skills profile becomes high risk

Annex III of the AI Act lists employment uses as high risk. Point 4(b) covers systems used to make decisions affecting terms of work relationships, to allocate tasks based on behaviour or personal traits, and to monitor and evaluate performance and behaviour.

A skills profile used only for course recommendations may sit outside that list. A skills profile used to shortlist people for internal roles, staff projects or plan promotions sits close to the centre of it.

The profiling rule closes the escape hatch

Article 6(3) lets some Annex III systems escape high-risk status if they perform only a narrow procedural or preparatory task and do not materially influence the decision. Vendors will reach for that derogation. The same article then says an Annex III system shall always be considered to be high-risk where the AI system performs profiling.

Skills inference evaluates personal aspects of a person by automated means. That is profiling in the GDPR sense the Act borrows. My reading is that a skills engine feeding any decision in point 4(b) cannot use the preparatory-task route, and I would plan on that basis rather than wait for a regulator to say so.

For deployers, Article 26(7) requires employers to inform workers' representatives and affected workers before using a high-risk system at the workplace. Article 26(11) adds a duty to tell people they are subject to it. Under Regulation (EU) 2026/1744, those obligations for Annex III systems now apply from 2 December 2027. What the transparency side demands is set out in the EU AI Act transparency checklist.

Where this argument is weakest

This post is built from vendor documentation and statute. Both have limits, and the counter-case deserves a fair hearing.

First, public documentation is not the product. "Not described publicly" in the table above may mean a control exists inside the admin console or the contract. Workday in particular publishes less on its marketing pages than it likely provides to customers under NDA. A buyer with the implementation guide may find the gaps closed.

Second, the case for skills inference is real. Self-reported skills profiles go stale, and managers' views of their teams are biased toward visibility. A model reading actual work can surface people whose skills nobody noticed. If internal mobility is the goal, a confirmed inferred profile may be fairer than the status quo, not less fair.

Third, the vendor figures here are thin. The 84.5% approval rate is one customer, reported by the vendor, and approval is not accuracy. Employees may approve flattering suggestions and reject accurate unflattering ones. I found no independent study measuring how often inferred skills match a validated assessment, and that absence should cut both ways.

Finally, the legal readings are mine, not a court's. Whether a specific skills engine counts as a monitoring device under German law, or as profiling under the AI Act, will turn on configuration and use. A tool that only recommends courses, with work-system inputs switched off, has a much stronger case for lighter treatment. The parallel debate on skills-based assessment validity is covered in the review of skills-based hiring assessments.

Frequently asked questions

Where to start before the rollout goes live

Pull one real employee's inferred profile from your pilot, with their permission, and trace every skill back to the record that produced it. If your vendor cannot show you that trail, you cannot answer an access request, and you should not go live.

Then write a one-page data-flow sheet listing each source system, the fields switched on, and who sees a suggestion before the employee does. Give that page to your data protection officer and, where one exists, your works council. It is the document every later negotiation will be built on.

Related reading