The Compliance Boundary PMs Must Draw Before Roadmapping

Two cards appear in a roadmap review. The first says, "Help a professional turn verified achievements into resume bullets." The second says, "Rank candidates for an employer." Both use career data and AI. Only one is intended for use in an employer's recruitment or selection workflow.

That change in purpose is a product boundary. It can alter the affected person, decision maker, data flow, evidence burden, human-oversight design, and regulatory exposure before the team selects a model.

This is product-management analysis, not legal advice, and it has not been reviewed by legal counsel. Regulatory sources were checked on 2026-07-13. Consult qualified counsel before classifying, selling, or deploying an actual system.

Early classification earns its place only if it identifies consequential scope changes before implementation and reduces redesign. If delayed review produces equal issue detection, architecture stability, and time to launch across comparable products, keep the later review.

Intended purpose can matter more than the model name

The portfolio describes Bragora as a user-side career workspace for capturing achievements, managing job applications, and turning work history into insight. That is an observed portfolio description, not a legal classification and not an independent test of every live capability.

Now consider a hypothetical extension sold to employers that filters applications or scores candidates. The underlying language model could be identical. The product role is different because the output enters another party's employment decision.

The enacted EU AI Act, Regulation (EU) 2024/1689 identifies certain employment uses in Annex III, including systems intended to place targeted job advertisements, analyze and filter applications, evaluate candidates, or influence work-related decisions. Article 6(3) provides a narrow derogation only when an Annex III system poses no significant risk, including no material influence on decisions, and meets one of four conditions: a narrow procedural task, improvement of completed human activity, pattern detection that does not replace or influence the completed human assessment without proper human review, or a preparatory task. Human review alone is not an exception. Profiling of natural persons in an Annex III use remains high-risk. A provider relying on the derogation must document the assessment before placing the system on the market or putting it into service and register it under Article 49(2).

Those provisions do not let a PM declare a product compliant or exempt from a feature description. Intended purpose, actual function, provider and deployer roles, material influence, profiling, jurisdiction, and surrounding law require legal analysis. The useful PM move is to expose those facts before implementation makes them expensive to change.

The scope tree asks who acts on whose opportunity

I would attach a Product-Scope Classification Tree to every roadmap item that touches employment, credit, health, education, housing, insurance, or public services. The artifact asks seven questions:

The answers produce a scope state, not a legal verdict.

State A is not a compliance-free zone. Consumer protection, privacy, accessibility, intellectual property, and sector rules may still apply. The tree is meant to trigger the right review, not wave it away.

A hypothetical Bragora extension shows how scope can drift

Start with the portfolio's user-side description. A professional selects achievements and asks for help drafting a bullet. The user can inspect the source, edit the sentence, and decide whether it leaves the workspace. That is the hypothetical State A baseline.

A customer request then arrives: "Let employers search these profiles and see a match score." The extension requires the team to assess and define, where applicable, employer accounts, candidate comparison, the scoring objective, validation evidence, group-level performance, notices, contestability, retention, access, and how the employer will use the score.

The roadmap may try to preserve the old label by calling the score "insight." Labels do not control product effect. If an employer sorts candidates by that output, the system may influence access to work regardless of the team's marketing language.

The enacted EU text makes intended purpose central. Article 25 addresses provider responsibility when a substantial modification leaves an existing high-risk system high-risk, or a changed intended purpose makes a previously non-high-risk system high-risk. In the United States, New York City's Department of Consumer and Worker Protection states that covered use in New York City requires a bias audit within one year before use, publication of a results summary, and notices. Counsel must determine whether a particular tool is covered.

The U.S. Equal Employment Opportunity Commission's guidance on employment tests and selection procedures explains that under Title VII, a neutral procedure that disproportionately excludes people based on race, color, religion, sex, or national origin may be unlawful unless job-related and consistent with business necessity. Other statutes use different tests. The document is nonbinding technical assistance, but it shows why evidence for a writing assistant cannot automatically support employer ranking.

The timeline itself is a product risk

The original Article 113 text generally applied the Act from 2 August 2026, subject to exceptions. Parliament and the Council subsequently adopted the Digital Omnibus on AI. The Council's final-adoption notice reports 2 December 2027 as the application date for stand-alone Annex III high-risk systems and says Official Journal publication follows. Before relying on that date, verify the final Official Journal citation, entry into force, system role, and any other applicable law.

The safest roadmap assumption is not that delay removes the work. Data lineage, intended-purpose documentation, role definitions, evaluation design, logging, notices, human oversight, and contestability are architecture decisions. They become harder to retrofit after enterprise contracts and model workflows are fixed.

Early review can protect speed when it produces a clear boundary

The counterargument is that compliance review before discovery will slow learning and turn every idea into a legal project. That can happen when the request is vague.

The scope tree makes the review smaller. A PM can state: this release is controlled by the individual; it does not rank or filter people for employers; it does not expose inferred traits to an institution; and any employer-side integration requires a new classification decision. Counsel can challenge a concrete boundary instead of reviewing an unlimited future.

Every sensitive-domain roadmap item should leave review with a short scope record. It needs one intended-purpose sentence, one explicit non-purpose, the person who controls the system, the person whose opportunity is affected, the output's influence on the decision, and the jurisdictions requiring review. Any move into institutional ranking, filtering, monitoring, or decision support opens a new product, evidence, and compliance gate.

The boundary is not a disclaimer at the bottom of a requirements document. It is a product decision about who receives power over whom. Draw it before the roadmap and keep it visible whenever the product's user, buyer, data flow, or decision role changes.