Article 5(1)(c) social scoring: requirements and evidence

What the Article 5(1)(c) social scoring ban asks for and where it stops

If a product team is asking whether a scoring feature is banned, the short answer is that Article 5(1)(c) prohibits AI systems that evaluate or classify people over time based on social behavior or personal characteristics, but only where the resulting score leads to detrimental or unfavorable treatment that falls into one of two categories. Credit scoring is not banned as such. It is a high-risk use under Annex III point 5(b), with financial fraud detection excluded. The ban targets a specific harm: a person's score from one part of life follows them into unrelated areas, or the consequences are out of proportion to the behavior that produced the score. The prohibition covers placing on the market, putting into service and use, so both the provider who builds the scoring model and the deployer who runs it can be caught. It has applied since 2 February 2025.

The first condition is that the treatment occurs in a social context unrelated to where the data was generated or collected. A product team should map each input signal to its origin, such as purchase history, social media activity, or location data, and ask whether the decision it feeds sits in the same setting. The second condition is that the treatment is unjustified or disproportionate to the social behavior or its gravity. Here the question is whether a minor lapse produces a severe consequence, such as blocking access to housing or public services. Both tests are applied to the system's actual use, not only to its stated purpose, so a feature built for one reason and reused elsewhere can change its legal position.

The hard part is the line between prohibited scoring and high-risk credit scoring. A lending model that uses repayment history and bank data to estimate creditworthiness is a high-risk system with conformity obligations, not a banned one. A model that draws on unrelated behavior, such as social contacts or browsing habits, to lower a person's standing across many services may fall under the ban. Teams should document the purpose and data sources of each score, record the decisions it feeds, and get written legal analysis before launch. The Commission's guidelines on prohibited practices, linked from this page's sources, are the next read on how the Commission interprets these tests. Confirm the classification with counsel, since an error here carries fines of up to EUR 35 million or 7% of worldwide annual turnover, whichever is higher.

Which systems, data and teams the social scoring ban reaches

Article 5(1)(c) turns on a handful of scoping questions: what the system does with people over time, what data feeds it, what treatment follows, and where that treatment lands. The cards below cover the decisions that change the work, the roles the ban binds, the EU nexus, and the third-party scores a deployer may buy in without building them.

Over-time evaluation or classification

The ban reaches systems that evaluate or classify natural persons or groups over a period of time. A one-off check, such as verifying an identity document at a single moment, sits outside this element. Map every system that produces a rating, rank, tier or score that is refreshed or reused across time. Record the update cadence and whether past outputs feed later decisions, because recurring scoring is the pattern the text describes.

Social behavior as the data source

Check whether inputs include social behavior, such as online activity, communications patterns, participation in community or civic life, or conduct toward others. The ban is aimed at scores built from how people behave socially. Log each data field feeding the model and label it as observed behavior, known personal characteristic, or inferred or predicted trait. Inferred and predicted traits count as much as recorded facts.

Personality and personal characteristics

The prohibition also covers scores built on known, inferred or predicted personal or personality characteristics. Profiles that estimate temperament, reliability, lifestyle or similar traits from data are in scope if the resulting score drives treatment. Document which traits the model estimates, who defined them, and whether any of them were derived by a vendor model that the organization cannot inspect. Unverified trait labels are a common source of hidden exposure.

Detrimental or unfavorable treatment

The score must lead to detrimental or unfavorable treatment for the ban to apply. Trace every downstream action that uses the score, including access restrictions, pricing changes, service denials, queue placement and escalations to enforcement. A score that only informs a human reviewer may still matter if the reviewer's outcome is effectively fixed by it. Record each action that a score can trigger and who can override it.

Unrelated context or disproportionate treatment

Treatment is caught when it occurs in a social context unrelated to where the data was generated or collected, or when it is unjustified or disproportionate to the social behavior or its gravity. For each scored use, compare the data origin with the context of the decision, such as a shopping record used to limit access to public services. Keep a written justification that links the penalty to the behavior it responds to. Credit scoring is a separate question, handled under the high-risk rules described below.

Roles the ban binds

The prohibition covers placing on the market, putting into service and use, so it binds both providers who build or sell a scoring system and deployers who run it. A deployer that configures a bought tool to rank people on social behavior is caught even if the vendor never intended that use. Assign an owner for each role in the inventory and confirm which entity signs the contracts and controls the production configuration.

EU nexus and Article 2 reach

Article 2 applies the Act to providers placing systems on the EU market wherever they are established, to deployers in the EU, and to non-EU providers and deployers whose output is used in the EU. A company outside the EU that scores EU residents, or whose scores are used in the EU, should treat the ban as applicable. Map where each scored individual is located and where each output is consumed, not only where servers run.

Third-party scores and vendor models

Many deployers buy scores from data brokers, credit bureaus or scoring vendors instead of building them. Buying does not remove the obligation to check the use. Request from each vendor a written description of the data sources, trait derivation, intended purposes and excluded uses. Confirm contractually whether the vendor will support audits of the score's use, and keep your own record of the decisions each purchased score informs.

How to tell a prohibited score from credit scoring

A score falls under Article 5(1)(c) when an AI system evaluates or classifies people over time based on social behavior or known, inferred or predicted personal or personality characteristics, and the resulting score leads to detrimental or unfavorable treatment. The prohibition applies where that treatment occurs in a social context unrelated to where the data was generated or collected, or where it is unjustified or disproportionate to the behavior or its gravity. Both limbs are tested separately, so a system can be banned even when the underlying data is accurate.

Context test: Ask whether the data was collected in one setting, such as online purchases, and the penalty applies in another, such as access to housing or public services.
Proportionality test: Ask whether the consequence matches the behavior. A minor late payment that triggers a broad service denial fails this test.
Time element: The prohibition targets scoring over time, so a single snapshot assessment is not the target of this ban.
Illustrative example: A municipal system that lowers a resident's access to permits after reading unpaid parking fines from unrelated social media activity would be a prohibited score.

Next obligation: stop placing the system on the market, putting it into service or using it, and document why it was withdrawn. The prohibition has applied since 2 February 2025, and fines reach EUR 35 million or 7% of worldwide annual turnover, whichever is higher.

How an assessor tests whether a scoring system is prohibited

This table walks through the questions a market surveillance authority or independent reviewer asks about a scoring system, in the order they usually arise, with the evidence each question requires. Read it as a checklist: a system that fails an early test may never reach the context question, but every gap should be documented either way.

Test question	What the reviewer looks for	Evidence that answers it
Is a score produced?	An output that evaluates or classifies a person or group and assigns a value, rank or category used later in decisions	System description, output schema, sample score records, scoring rules
Is the evaluation made over time?	Repeated or accumulated assessment of behavior across a period, not a one-off classification at a single point	Data pipeline design, retention settings, logs showing how past events feed current scores
Which data and characteristics feed the score?	Social behavior, or known, inferred or predicted personal or personality traits, and whether data was collected for another purpose	Data inventory with source, original purpose, legal basis and any inferred attributes
Where is the score applied?	Whether the score is used in contexts unrelated to where the data was generated or collected	Downstream use case register listing each consuming service, team and decision
Does the treatment follow from the score?	Detrimental or unfavorable treatment resulting from the score, such as denial, restriction or reduced access	Decision logs linking score values to outcomes, appeal records, override rules
Is the treatment justified and proportionate?	A documented link between the behavior assessed and the gravity of the consequence	Justification memo, proportionality analysis, approval records from the accountable owner
Where does credit scoring sit?	Creditworthiness assessment is not banned as such but is high-risk under Annex III, with financial fraud detection excluded	Purpose statement, scope boundary document, Annex III classification record for each credit model
Are scores reused across unrelated services?	A common score feeding HR, insurance, housing or access decisions unrelated to the original data context	Data flow diagrams, access control lists for score stores, reuse approval log

How to confirm a scoring feature sits outside the ban, step by step

This sequence shows how an organization decides whether a scoring feature falls under the Article 5(1)(c) prohibition, is a lawful score, or is credit scoring that must be routed to the high-risk obligations. Each step ends with a written artifact that a reviewer can check.

Inventory every system that produces a score
Start by listing each AI system, model, rule set or analytics job that evaluates or classifies people over time, including scores labeled as risk, trust, reputation, propensity, priority or engagement. Include systems bought from vendors and features inside SaaS products, because the prohibition covers placing on the market, putting into service and use. Assign each entry an owner and note whether your organization is the provider, the deployer or both. The step closes with a register of scoring systems that the compliance team can sign off, and an explicit statement for any system found to produce no person-level score.
Map each score to its inputs and decisions
For each entry in the register, record where the data came from, whether it was generated in one social context and used in another, and which downstream decisions the score feeds, such as pricing, access, prioritization, eligibility or monitoring. Separate observed behavior from known, inferred or predicted personal characteristics, because the ban covers all three. Record who sees the output and whether a person can see or contest it. The step closes with a data and decision map per system, which becomes the factual basis for the legal test in the next step.
Run the context and proportionality test
Test each mapped flow against the two conditions in Article 5(1)(c): whether the detrimental or unfavorable treatment occurs in a social context unrelated to where the data was generated or collected, and whether the treatment is unjustified or disproportionate to the social behavior or its gravity. A flow that fails either condition is a candidate for the prohibition, and a flow that passes both still needs the evaluation in the next steps. Involve the business owner, a privacy lead and counsel, and document each finding in plain terms. The step closes with a signed test sheet per flow, with the conclusion marked as prohibited candidate, not triggered, or needs further review.
Document the conclusion with legal review
Write a short memo for each system that states the scoring purpose, the data sources, the decisions affected, the result of the context and proportionality test, and the reasons for the conclusion. Have qualified counsel review the memo, because the Commission's guidelines on prohibited practices are interpretive material and do not replace legal advice on your facts. Confirm the current text of the Commission's guidelines and the Act before relying on them, since the 2026 amendments changed the surrounding framework. The step closes with an approved memo per system, stored with the register so an assessor or regulator can trace the reasoning.
Route credit scoring to the high-risk obligations
Where a system evaluates creditworthiness or sets credit scores, the social scoring ban is not the controlling test. Check Annex III point 5(b), which classifies credit evaluation as high-risk, and confirm whether the system falls under the financial fraud detection exclusion that the annex states. If it is high-risk, open a separate compliance track for the requirements in Chapter III and the provider or deployer duties that apply to your role. The step closes with a high-risk classification record for each credit system, linked to the system register, and an assigned owner for the Chapter III workstream.
Set re-check triggers for new data and uses
A conclusion made today can change when a team adds a data source, reuses a score for a new decision, or enlarges the population scored. Define the events that reopen the test, such as a new data feed, a new consumer of the score, a change in the decision it drives, or a material model update, and wire them into change management and procurement reviews. Assign an owner for monitoring these triggers and for re-running the test. The step closes with a documented trigger list and a review log that records each re-check and its result.
Keep the evidence ready for assessment
Store the register, data and decision maps, signed test sheets, memos, classification records and trigger logs in one controlled location with version history. Confirm which of these artifacts your internal audit, customers or market surveillance authority are likely to request, and check that each one can be produced without rebuilding it from memory. Because DeployOpen prepares systems and evidence but does not issue assessment reports, any independent review of these conclusions remains the responsibility of your own counsel, auditors or the authorities concerned. The step closes with an indexed evidence folder reviewed once by the compliance lead.

Evidence that shows a scoring system stays outside the ban

Article 5(1)(c) turns on facts you can show: what the system scores, what data feeds it, where the score is used, and why any detrimental treatment is tied to the behavior that produced it. The artifacts below record those facts, so an assessor or market surveillance authority can test the boundary without relying on your assurances. Keep each one dated and owned, and review them together whenever the scoring logic or its uses change.

Scoring system register entry

Record each system that evaluates or classifies people over time, with its owner, its stated purpose, every downstream use of the score, and the decisions it feeds. Include any internal dashboard, ranking or eligibility flag that consumes the output, not only the vendor product. The register is the starting point for every other artifact, so check it first whenever a new consumer of the score appears. Ask whether a downstream team has started using a score for a purpose the register does not name, because that gap is where a context problem begins.

Data source and characteristic register

List every data source and personal characteristic that enters the score, including inferred or predicted attributes that a model generates about a person. For each entry, record where the data was originally generated or collected and whether it was collected for the context where the score now applies. Mismatches between collection context and use context are the core facts the prohibition examines. Review this register when a new feed is connected, and confirm with your data protection team that each source has a lawful basis for the new use.

Context and proportionality analysis

Document why the treatment that follows a score is connected to the behavior it measures and why it is proportionate to that behavior's gravity. Describe the social contexts where the score is applied and show that none of them is unrelated to where the underlying data was generated, unless you can justify the link. Write the analysis as a decision record that a reviewer can challenge line by line. Refresh it when the treatment changes, since a harmless-looking eligibility rule can become disproportionate after a policy update.

Legal determination on credit scoring

Where a score assesses creditworthiness, record the determination that it falls under the credit scoring carve-out rather than the social scoring prohibition, and explain why the score does not evaluate general social behavior. Annex III point 5(b) classifies creditworthiness evaluation as high-risk, so this determination also sets the obligations that follow. Have counsel sign the determination, and revisit it whenever the input features or the decisions it drives expand beyond credit.

Decision and output logs

Keep logs that tie each score to its inputs, output, model or rule version, and the decision that used it. For LLM-based scoring components, Langfuse traces can capture inputs, outputs, token usage and metadata for each call, which helps reconstruct how a score was produced. Confirm how traces are retained, redacted and access controlled in your own stack, because personal data in logs carries its own obligations. Test periodically that a sampled decision can be traced end to end.

Change records and inventory

Record every change to features, weights, thresholds, data sources and downstream uses, with the approver and the date. Hold the inventory and assessment records for these systems in a governance tool such as CISO Assistant, which can hold inventory and assessment records against frameworks, but confirm that it fits your AI governance workflow before relying on it for this purpose. Link each change to an updated register entry and proportionality review, so a reviewer can see that no change moved the score into an unrelated context without a decision on record.

What staying outside the social scoring ban costs in money and effort

This table compares each cost component of keeping a scoring system outside the Article 5(1)(c) ban, showing whether it is one-time or recurring, what drives it up, and how to reduce it. Use it to frame a quote request, and note that no fee figures are given because none are supplied for this topic. The main takeaway is that the largest recurring cost is re-review after model or data changes, so scope it tightly from the start.

Cost component	One-time or recurring	What drives it up and how to reduce it
Legal analysis of the scoring boundary	One-time at setup, then recurring when use changes	Drivers: number of scoring systems, data sources and jurisdictions. Reduce by documenting each system's purpose and context before engaging counsel, and by asking for a written opinion per system.
Engineering time for the AI system inventory and logs	One-time build, recurring upkeep	Drivers: count of models, pipelines and third-party scores in use. Reduce with self-hosted tracing such as Langfuse (MIT) to capture inputs, outputs and metadata without license spend.
Data mapping effort	One-time for the initial map, recurring as data sources change	Drivers: number of data sources and whether behavioral or inferred traits are used. Reduce by mapping each feature to its origin context so cross-context use is visible early.
Periodic re-review after model or data changes	Recurring	Drivers: release frequency, retraining cadence and new features added to scoring. Reduce by tying review to your change management process and defining which changes trigger a new legal check.
Testing of language model components, where used	One-time setup, recurring on each model update	Drivers: number of language model components and the test scope. Reduce by running open-source probes such as garak (Apache-2.0) and retaining its JSONL reports as evidence.
External legal or assessor review	Recurring at set points, plus ad hoc	Drivers: complexity of the boundary and the number of jurisdictions. Ask for a fixed-scope quote with named deliverables, the review standard applied, and whether re-review after change is included.
Penalty exposure if the boundary is wrong	Contingent, not budgeted	Article 99(3) sets fines of up to EUR 35 million or 7% of total worldwide annual turnover for the preceding financial year, whichever is higher. Reduce exposure by settling the classification before launch.

Who owns the boundary decision, who prepares the evidence, and who reviews it

Your organization owns the decision on whether any scoring system falls under Article 5(1)(c). Legal counsel interprets the two limbs of the prohibition, product owners describe what the system actually does with data over time, data and platform engineers confirm which inputs feed the score and where outputs travel, and compliance records the conclusion and who approved it. This is the only group that can say whether a score is used in an unrelated social context or whether a treatment is disproportionate to the behavior involved.

Legal conclusion: Counsel documents why a system is or is not prohibited, with reference to the Article 5 text and the Commission's guidelines.
Use case description: Product owners state the inputs, time window, output and every downstream decision the score can trigger.
Data lineage: Engineers trace where each input originated, so the team can test whether data reused in another context.
Sign-off record: Compliance keeps the dated approval, the reviewer names and the conditions attached to the decision.

Before relying on any outside help, check that the internal owner can explain the boundary decision without referring to a vendor document.

Where organizations get social scoring wrong and how to close each gap

Most social scoring problems in practice come from scores that were built for one purpose and then drifted into another, or from data and models that the organization cannot explain. Each gap below ties to the Article 5(1)(c) test: whether a score leads to detrimental treatment in an unrelated context or treatment that is unjustified or disproportionate. The fixes are mostly governance and records, so the evidence an assessor will ask for is usually something you can produce before the question is asked.

Fraud score reused for pricing

A model built to detect fraud is later used to set prices, limits or marketing offers. The data was collected for one purpose, and the output now drives treatment in a different social context, which is the pattern Article 5(1)(c) targets. Fix this by writing a purpose statement for every score and blocking reuse in the access control layer. Artifact: a score register entry listing the intended purpose, the permitted decisions and the owner who approved any change. Check whether each new consumer appears in that register.

Third-party data without context analysis

Scores often combine data bought from brokers, public records or partners with the organization's own records. Without a documented context analysis, nobody can show that the data's original context is related to the decision it now informs. Ask each data supplier where and how the data was generated, and record whether the use is connected to that context. Artifact: a data provenance and context assessment per data source, signed off before the data enters the scoring pipeline.

Credit models drifting into behavioral scoring

A creditworthiness model is expected to stay within its lending purpose, but teams often add behavioral signals such as app usage, social connections or purchase habits to improve accuracy. Credit scoring is not prohibited as such, yet Annex III point 5(b) makes it high-risk, and behavioral features can move the system toward the Article 5 line. Fix this by freezing the feature list under change control and reviewing every new feature against its link to creditworthiness. Artifact: a versioned feature inventory with a documented rationale for each input.

No record of score-to-decision links

When a customer is refused a service, the organization often cannot say which score fed the decision, what value it had and which system acted on it. That gap makes proportionality and disproportionality impossible to test. Log each score produced, its model version, the decision it informed and the human or automated step that applied it. Artifact: a decision log that joins score IDs to downstream outcomes, retained long enough to answer complaints and authority requests.

Vendor models with unknown training inputs

Organizations often buy scoring models or APIs without knowing what data trained them or which social characteristics the vendor infers. The deployer remains responsible for how the output is used, so an unknown training base is a direct compliance risk. Require the vendor to document training data sources, prohibited features and intended uses in writing before procurement. Artifact: a vendor due diligence file containing the model documentation, the contractual use limits and your own test results on representative data.

Disproportionate treatment without review

Even a justified score can cause treatment that is harsher than the behavior it measures warrants. Teams rarely test whether penalties scale with gravity, so a minor data gap can trigger a service block. Define the treatment tiers in advance, test outcomes across customer groups, and route adverse actions above a set severity to a trained reviewer. Artifact: a documented proportionality review with test cases, outcome statistics by group and the reviewer's sign-off on high-impact decisions.

Questions buyers ask about the social scoring ban

How much effort does the social scoring boundary analysis take?

The effort depends on how many AI systems you run that score, rank or classify people, and how many of them touch decisions about access to services, benefits or opportunities. Each system needs a documented test of three things: whether it scores people over time on social behavior or personal characteristics, whether the resulting score leads to detrimental treatment, and whether that treatment falls in an unrelated social context or is unjustified or disproportionate to the behavior. A single HR screening tool or a customer risk model can take a few working sessions to document. A portfolio of models with shared data pipelines takes longer because each one needs its own record. The main cost driver is the number of systems and the availability of people who can explain how each score is built and used. Ask any advisor for a fixed scope listing the systems to be reviewed and the outputs expected.

How long does a social scoring review take, and what does it need from our team?

The duration depends on the scope and on how quickly your team can produce accurate information, so no fixed timeline applies to every organization. The work needs a named business owner for each system, an engineer who can describe the data inputs and the logic that produces a score, and someone who knows where scores are shared or acted upon. Legal or compliance counsel must confirm the classification, because the prohibition turns on legal tests about context and proportionality. Plan for the review to slow down when data lineage is unclear or when scores feed several downstream systems. Ask for a written schedule with the dependencies on your side listed as milestones, so that delays in supplying information are visible early.

Can we do the social scoring review in-house?

Yes, an organization can run the boundary analysis itself, and many will need to keep the decision in-house regardless. The decision on whether a system is prohibited is a legal and governance call, so the accountable owner should be your legal, compliance or AI governance function. Outside help is usually most useful for mapping data flows, reviewing technical documentation, and preparing the evidence record. DeployOpen can help prepare systems and evidence inside your own infrastructure, but it does not make legal determinations and does not issue assessments or certifications. Independent auditors and certification bodies issue those. Decide internally which questions must be answered by counsel and which by engineers before you buy any outside support.

Is credit scoring banned under the EU AI Act?

No, credit scoring is not banned as such. Article 5(1)(c) prohibits social scoring that leads to unrelated or disproportionate detrimental treatment, but evaluating creditworthiness or setting credit scores is treated differently. Annex III point 5(b) classifies AI systems used to evaluate the creditworthiness of natural persons or establish their credit score as high-risk, and it excludes AI systems used for detecting financial fraud. That means a lending model must meet the high-risk requirements instead of being prohibited. Whether a particular credit model falls under the ban or under the high-risk category depends on its inputs and use, so confirm the classification with counsel before relying on it. Lenders should also check the separate lending and financial sector rules that apply alongside the Act.

What fines apply if we breach the social scoring prohibition?

Breaching Article 5(1)(c) can lead to fines of up to EUR 35 million or, for an undertaking, 7% of total worldwide annual turnover for the preceding financial year, whichever is higher, under Article 99(3). The higher of the two figures applies, so for large groups the percentage usually sets the ceiling. The fine is a maximum, and the actual amount depends on the circumstances, the nature of the breach and the cooperation shown. Fines are only one exposure, since the prohibition also restricts placing the system on the market, putting it into service and using it. Confirm the exposure for your group with counsel, including any national enforcement rules that apply.

When did the social scoring prohibition start to apply?

The prohibition has applied since 2 February 2025, as set out in Article 113 of the AI Act. Systems that were already on the market or in use when it began are still subject to the ban, so there is no grandfathering period for prohibited practices. Organizations should therefore review existing scoring systems now rather than waiting for the high-risk dates that apply later in the Act. Confirm with counsel how the start date interacts with any transitional arrangements that apply to your specific systems.

How DeployOpen works on this

DeployOpen helps organizations that build or run AI systems check whether any system scores people over time in a way Article 5(1)(c) would prohibit, and prepares the system records that show the answer. DeployOpen prepares systems and evidence only; the organization owns its legal conclusions, and an independent assessor or legal advisor issues any formal opinion.

How we scope

Written scope lists every AI system, scoring model and data flow that could rank or classify people in the organization.
Each in-scope system is checked for the three conditions: time-based scoring, social or personal characteristics, and detrimental treatment.
Fixed-scope engagements agree deliverables and timelines in writing before any work starts, and ongoing support is available as a retainer.

How we build

Data lineage records show where scoring inputs were collected, so the team can test whether outputs reach unrelated social contexts.
Logging and tracing with self-hosted tools such as Langfuse capture inputs, outputs and decision paths for each scoring request.
Test cases probe whether a model ranks people on social behavior or personal traits and whether the output drives disproportionate treatment.

How we hand over

A documented inventory records each system, its purpose, its inputs, its outputs and the owner who decided it falls outside Article 5(1)(c).
Evidence packs contain configuration records, test results, decision logs and the reasoning behind each scope boundary decision.
Handover includes a short walkthrough so the client's compliance and engineering staff can explain the evidence to an assessor.

How we support

Retainers cover re-checks when a scoring model, its training data or its downstream use changes.
Security testing of AI systems and agents can probe scoring pipelines for unintended ranking behavior before release.
Clients confirm with their legal counsel and any supervisory authority which conclusions they need in writing, and DeployOpen supplies the evidence for that review.