AI Regulation for Portuguese Companies: A Practical Compliance Guide

Artificial intelligence is becoming ordinary infrastructure for Portuguese companies. A commercial team uses a language model to draft proposals, a contact centre summarises calls, a factory predicts maintenance, a bank reviews documents, a retailer personalises offers, and an HR department searches and ranks applications. The useful question is no longer whether your company uses AI. It is whether you know which systems are running, what information they receive, who may be affected, what decisions they influence, and whether you can demonstrate control when a customer, worker, regulator, auditor, board, or business partner asks.

This guide is written for companies established in Portugal and for companies selling into Portugal or the wider European Union. It describes the legal and operating position as of September 2026. It is practical compliance guidance, not legal advice. The EU AI Act has a staged application model, Portuguese institutional arrangements continue to develop, and sector rules can change the answer. Confirm the scope, deadlines, exemptions, and enforcement position for your specific business with qualified Portuguese or EU counsel before relying on this article for a high impact launch.

The short answer for Portuguese companies

Portugal does not have a separate comprehensive AI code that replaces European law. The central framework is Regulation (EU) 2024/1689, the Artificial Intelligence Act, directly applicable across the European Union. It works alongside the General Data Protection Regulation, the Portuguese law that implements the GDPR, consumer and employment law, cybersecurity requirements, sector regulation, intellectual property law, product safety rules, and contracts. A model supplied by an American or Asian vendor does not make Portuguese obligations disappear. A company can be a provider, deployer, importer, distributor, product manufacturer, or more than one of these at the same time.

Start by separating legal status from good practice. A regulation, statute, enforceable decision, or contractual commitment is binding within its scope. A European Commission FAQ, CNPD recommendation, European Data Protection Board opinion, harmonised standard, or industry code can be influential and useful without having exactly the same legal force. A national strategy, consultation, political announcement, draft law, or proposal is not a current duty merely because it discusses AI. Keep these categories visible in your legal register so that management does not mistake a proposal for law or overlook a binding rule that predates AI.

What the EU AI Act does

The AI Act is a risk based product and use regulation. It applies to actors inside and outside the EU when the system is placed on the Union market, put into service in the Union, or its output is used in the Union, subject to the Regulation's detailed territorial rules. It distinguishes prohibited practices, high risk systems, transparency obligations for certain systems, and general purpose AI models. Many ordinary productivity uses will not be high risk under the Act, but they can still create GDPR, confidentiality, discrimination, consumer protection, security, or contractual exposure.

Prohibited practices include specified uses such as certain manipulative or deceptive techniques, exploitation of vulnerabilities, social scoring, and some biometric or emotion recognition practices. The exact wording and exceptions in Article 5 matter. Do not classify a use from a marketing label or a short summary. Read the current Regulation and the Commission's guidance on prohibited practices and definitions. Some practices can be unlawful even when the system is accurate, inexpensive, or accepted by the business user.

High risk status can arise because an AI system is a safety component or product covered by Annex I legislation, or because it is used in an Annex III area such as biometrics, critical infrastructure, education, employment, access to essential private or public services, law enforcement, migration, or justice. Classification depends on the system's intended purpose and the legal conditions, including exclusions and exceptions. A recommendation engine used to rank job applicants deserves a very different assessment from a tool that corrects spelling in an internal memo.

For a high risk system, providers and deployers should expect structured controls covering risk management, data and data governance, technical documentation, records and logging, transparency, human oversight, accuracy, robustness, cybersecurity, quality management, conformity assessment, and post-market monitoring. The obligations are allocated differently depending on whether your company develops the system, changes it, imports it, distributes it, or deploys it. A buyer cannot assume that the supplier's conformity work covers the buyer's deployment duties.

The implementation timeline as of September 2026

The AI Act entered into force on 1 August 2024. The original two year timetable has been modified by the AI Omnibus, which entered into force on 27 July 2026. Use the consolidated text on EUR-Lex and the European Commission implementation page as the source of truth. The dates below are a planning summary, not a substitute for checking the applicable article, transition rule, or later amendment.

• Since 2 February 2025, the definitions, general provisions, and prohibitions have applied, together with the AI literacy obligation in Article 4.
• Since 2 August 2025, the governance rules and obligations for general purpose AI models have applied, subject to the Regulation's provider and transition provisions.
• From 2 August 2026, the main framework is applicable and the AI Office and Member State authorities have enforcement powers, while the amended transition dates affect particular high risk categories.
• From 2 December 2026, the specific prohibition concerning generation or manipulation of non-consensual intimate material and child sexual abuse material applies under the current Commission timeline.
• From 2 December 2027, rules for high risk use cases listed in Annex III apply under the AI Omnibus extension, including sensitive employment and access to services uses.
• From 2 August 2028, rules for high risk AI embedded in regulated products covered by Annex I apply under the extended transition.

The extension of the high risk dates is not a compliance holiday. Prohibitions, AI literacy, general purpose model duties, transparency rules, GDPR obligations, employment rights, product safety, and contractual controls can apply before the later high risk dates. A company buying a high risk capable tool should use the available preparation period to classify the intended purpose, collect supplier evidence, test the workflow, and create human oversight. When a deadline moves, treat the register as updated, not the risk as deleted.

Harmonised standards can help establish a presumption of conformity when referenced and available, but a standard is not automatically a law. Draft Commission guidelines on classification and high risk systems are non-binding interpretive material. They may be highly relevant to enforcement and should be monitored, but label them as guidance in the register. Likewise, a voluntary code of conduct, technical standard, or internal control can be adopted as a contractual or governance requirement without being described as a statutory obligation.

Portugal's authorities and the role of CNPD

The CNPD, Comissão Nacional de Proteção de Dados, is Portugal's independent data protection supervisory authority. Under the GDPR and Portuguese Law 58/2019, it supervises the processing of personal data and protects the rights and freedoms of individuals. If an AI system processes personal data, the CNPD remains relevant even when the immediate issue is presented as model quality, automation, or innovation. It can examine legal basis, transparency, purpose limitation, minimisation, security, data subject rights, profiling, automated decisions, DPIAs, and international transfers.

The CNPD is not a universal substitute for every AI regulator. The AI Act requires Member States to designate at least a notifying authority and market surveillance authorities, with roles coordinated through the European AI Board. The authority for a given product or use can depend on the sector, product legislation, provider or deployer role, and the Portuguese designation in force. In practice, companies should maintain an authority map that includes CNPD for data protection, the relevant sector regulator, labour and workplace bodies where employment issues arise, consumer authorities where relevant, and the designated AI Act contacts once confirmed in the official Portuguese framework.

Do not describe the national AI governance strategy as an enforcement designation. Portugal's Agenda Nacional de Inteligência Artificial, approved by Resolution of the Council of Ministers 2/2026, is a strategic and policy instrument that supports adoption, skills, research, infrastructure, and alignment with European priorities. It identifies actions and public coordination. It is not, by itself, a private company's complete AI compliance code or a replacement for the EU Regulation. The Digital Strategy and related 2026 government measures are useful context, while binding duties still come from the applicable legal instruments.

GDPR is still the first control layer

The AI Act does not create a lawful basis for processing personal data. Before an AI use goes live, identify the controller and processor roles, the purpose, the legal basis, the categories of data, the people affected, recipients, retention period, locations, security measures, and rights route. Legitimate interests require a real balancing assessment. Consent must be informed and meaningful. Contract necessity has limits. Public interest and legal obligation need a proper legal foundation. Do not use the phrase the model needs the data as a substitute for a lawful basis and necessity analysis.

Purpose limitation becomes difficult when a vendor uses prompts, uploaded files, feedback, or telemetry to improve a general model. Separate your purpose from the vendor's secondary purpose. Record whether information is used for inference, retrieval, evaluation, fine tuning, abuse prevention, monitoring, or training. Confirm the setting in the contract and the actual product configuration. A customer who sent a document to obtain support may not have expected that document to train a general service. A job applicant who supplied a CV for recruitment did not automatically agree to product development.

Minimise before you anonymise. Removing a name does not necessarily remove identifiability when dates, location, job title, free text, account details, images, voice, or distinctive facts remain. Use field filtering, redaction, pseudonymisation, tokenisation, access controls, separate test data, and short retention. Cover prompts, outputs, embeddings, retrieval indexes, evaluation sets, telemetry, backups, and incident tickets. Ensure that a deletion or access process can find relevant derived data where required and technically feasible.

The EDPB's Opinion 28/2024 on AI models is not a new regulation, but it is useful official guidance on anonymity, legitimate interests, data minimisation, transparency, and individual rights. It reinforces a practical point: processing during training and processing during deployment need separate analysis. Document what is known about the model's source data and what your own company does with personal data. If a supplier cannot explain its data practices sufficiently for your risk, that is a procurement finding, not an issue to hide in a privacy notice.

DPIAs, profiling, and automated decisions

Article 35 GDPR requires a data protection impact assessment when processing is likely to result in a high risk to individuals, including certain large scale processing of sensitive data, systematic monitoring, and profiling or automated decisions with significant effects. The CNPD publishes practical information on DPIAs and its list of processing types that require one. An AI impact review can include broader safety, fairness, security, and operational questions, but it does not replace a DPIA when Article 35 requires one.

Article 22 GDPR gives individuals a right not to be subject to a decision based solely on automated processing, including profiling, when it produces legal effects or similarly significantly affects them. There are narrow exceptions connected with contract necessity, Union or Member State law, or explicit consent, and the safeguards in Article 22(3) still matter. The data subject should have a route to obtain human intervention, express a point of view, and contest the decision where the provision applies.

A decision can be effectively automated even when a person presses the final button. Ask whether the reviewer sees the relevant evidence, understands the model's limitations, has enough time, is trained for the task, can investigate source errors, has authority to disagree, and actually changes results. A person who approves every score without meaningful review is not a reliable safeguard. The Court of Justice judgment in SCHUFA is a useful warning that an algorithmic score can be part of a significant decision even when another organisation formally takes the final step.

Explainability should reflect the actual workflow. Tell the person that profiling or automated assistance is used where required, describe the purpose and categories of information, identify the meaningful factors or process, state the limitations, and provide a practical correction and appeal route. Do not promise a mathematical explanation that the system cannot produce. Do not conceal a consequential ranking behind the word recommendation. The result, reviewer action, reasons, and challenge outcome should be recorded in a proportionate way.

Employment and worker protection

Employment uses deserve a distinct review because they affect livelihoods, dignity, equality, privacy, and workplace power. AI may rank applicants, analyse interviews, recommend shifts, monitor activity, predict absence, evaluate performance, suggest discipline, or select people for redundancy. The Portuguese Labour Code, equal treatment rules, workplace privacy principles, collective instruments, occupational safety duties, and GDPR can apply even where the AI Act high risk provisions are on a later transition date.

The AI Act treats many employment and worker management uses as sensitive high risk use cases. The relevant legal classification should be checked against the current Annex III text and intended purpose. In addition, Article 22 GDPR may apply to a fully automated significant decision, while Articles 13 and 14 require transparent information in relevant circumstances. Sensitive data and inferred traits create additional risk. A company should never use an automated score as the sole basis for hiring, promotion, discipline, dismissal, pay, or access to an essential workplace benefit without specialist legal review and a genuine human decision process.

Consultation and communication are part of responsible deployment. Explain to workers and candidates what the system does, what it does not do, which human retains authority, and how to challenge an error or request accommodation. Involve HR, the data protection officer, legal, security, health and safety, and worker representatives or unions where required or appropriate. Test language and accessibility, including Portuguese language variation and disability related accommodations. Do not let a vendor's benchmark substitute for a job relevance, equality, or workplace impact assessment.

AI literacy is a real operational duty

Article 4 of the AI Act requires providers and deployers to take measures to support AI literacy for staff and other people operating or using AI on their behalf. The requirement is contextual. It considers technical knowledge, experience, education, training, the system, and the people or groups on whom it is used. It does not require a company to guarantee a specific level of knowledge in every individual, but it does require a credible effort. Since the obligation has applied since 2 February 2025, it belongs in today's programme, not a future project plan.

A one hour generic e-learning module will rarely be enough for every role. Train sales staff on confidential information, hallucinations, copyright, verification, and disclosure. Train customer service staff on escalation and account security. Train HR reviewers on automation bias, accommodation, discrimination, and challenge routes. Train engineers on threat modelling, evaluation, permissions, logging, prompt injection, and rollback. Train managers on accountability, evidence, and when to stop a deployment. Keep attendance, content, role mapping, exercises, assessment results, refresh dates, and exceptions.

Literacy should include affected people where the context requires useful communication. A customer should know when they are dealing with a bot if that fact matters, how to reach a person, and how to correct an outcome. A worker should understand monitoring and evaluation that affect them. A reviewer should know that an output is a probability or recommendation, not a fact. The Commission's examples and living resources can inform a programme, while internal training remains the company's responsibility.

Sector rules do not disappear into AI

A horizontal AI assessment is only one layer. A bank or fintech should connect AI governance to prudential expectations, outsourcing, model risk, consumer protection, anti money laundering, credit assessment, payment security, complaint handling, and Banco de Portugal or other applicable supervision. An insurer should examine underwriting, pricing, claims, fraud flags, explanations, and discrimination. A health organisation or supplier should consider medical device rules, clinical safety, professional duties, patient confidentiality, and the EU health data framework.

Manufacturers should connect AI controls to machinery, product safety, quality, industrial cybersecurity, and workplace safety. Energy, transport, logistics, and utilities should examine operational resilience, critical infrastructure, safety, environmental obligations, and incident response. Schools and education suppliers should review children, assessment integrity, biometric and emotion recognition restrictions, accessibility, and safeguarding. Retail and hospitality businesses should consider consumer profiling, targeted marketing, pricing, loyalty data, payment information, and accessibility. Public procurement can add transparency, audit, security, and data residency clauses.

Create a sector sign off route. A privacy approval is not a clinical approval. A security review is not an employment equality review. A model validation report is not proof that a safety process is adequate. The responsible specialist should be able to pause deployment when the evidence is incomplete, and that authority should be written into the governance procedure rather than depending on personal courage during a launch meeting.

Build an inventory before writing a policy

A policy drafted before discovery describes an imaginary company. Ask every function to list purchased software, embedded AI features, APIs, experiments, browser extensions, open source models, spreadsheet add ons, agents, and uses created without procurement approval. Reconcile responses against software asset records, cloud invoices, identity groups, expense claims, data processing registers, product roadmaps, vendor questionnaires, and security logs. Shadow AI is a governance finding. It should be brought into a controlled process, not omitted because it was not formally approved.

• System, feature, model or provider, version, owner, users, purpose, lifecycle stage, and connected actions.
• Input data, output recipients, personal and special category data, confidential material, children's data, biometrics, retention, and hosting locations.
• Affected people, language, geography, sector, decision impact, autonomy, human review, override authority, and ability to stop.
• Provider role, contract, subprocessors, training settings, support access, security controls, incident contact, and exit plan.
• Known limitations, evaluation results, fairness and accuracy concerns, legal classification, open questions, and next review date.

Use an internal risk tier that supports decisions, while clearly stating that your tier names are not a replacement for the AI Act's legal classification. A low tier might cover drafting or summarisation with no sensitive inputs and no decision effect. A medium tier might cover internal retrieval, customer interaction, or workflow recommendations that require verification. A high tier might cover employment, credit, health, eligibility, safety, biometrics, essential services, legal rights, or autonomous action. A prohibited tier should stop uses that violate law or cannot be governed with available evidence.

Reclassify whenever the model, data source, user group, geography, connected tool, output recipient, or business purpose changes. A low risk writing assistant can become high risk when it receives customer files. A support chatbot can become consequential when it can change an account or deny a refund. Record the legal classification separately from the internal tier, why each decision was made, who accepted residual risk, and what event triggers a new review.

Governance roles that work

Assign accountability at the use case level. An executive sponsor owns risk appetite, resources, and unresolved decisions. The privacy officer or DPO owns data protection interpretation and rights processes. Security owns threat modelling, permissions, monitoring, and response coordination. Product and engineering own design, testing, release, and technical change control. Operations owns the process and human review. Procurement owns supplier evidence and contract terms. HR, legal, finance, quality, health and safety, and sector specialists join when the use demands them.

Do not create a committee that approves everything but owns nothing. Use a short decision record containing the system, intended purpose, legal roles, AI Act classification, internal tier, data flow, affected people, controls, open risks, approval conditions, owner, and review date. Give the reviewer authority to pause launch. The owner remains accountable after release, including for evidence, incidents, changes, user feedback, and retirement. Governance should connect to procurement, identity, product release, privacy, security, HR, and service management rather than live in a separate spreadsheet.

Vendor controls and procurement

Buying an AI feature does not transfer all responsibility to the supplier. The provider controls parts of the model and infrastructure; your company controls the business purpose, configuration, users, data, instructions, integrations, and downstream decisions. Classify the service before accepting standard terms. A private writing assistant and an automated claims triage engine should not receive the same due diligence or contract.

• Identify the supplier's role, model family, material versions, hosting countries, subprocessors, support access, and change process.
• Specify whether prompts, files, outputs, feedback, telemetry, and evaluation data are retained or used for training, fine tuning, or other secondary purposes.
• Require security, privacy, retention, deletion, access, transfer, breach, incident, and regulatory cooperation commitments appropriate to the use.
• Require advance notice and a review right for material model, data use, hosting, subprocessor, functionality, or risk changes.
• Define service limits, human escalation, audit evidence, export, rollback, business continuity, portability, and termination assistance.
• Require disclosure of known limitations, evaluation results, prohibited uses, content provenance features, and the supplier's role under the AI Act.

Ask for evidence, not a badge. A statement that a product is AI Act compliant is not a classification decision, conformity assessment, DPIA, security assessment, or guarantee that the configured service matches your purpose. Review the contract, data processing terms, technical documentation, model card, independent assurance, incident history, service settings, support process, and change notices. For a critical use, test a vendor outage, export your records, and confirm that your company can safely pause or replace the service.

Human oversight that is more than a checkbox

Design human oversight before deployment. Define which outputs require review, what information the reviewer receives, which thresholds trigger escalation, what the reviewer must verify, how disagreement is recorded, who can override or stop an action, and how affected people can challenge an outcome. For a system that sends messages, changes records, approves payments, or prioritises safety work, use least privilege, transaction limits, confirmation steps, and reversible actions.

Measure the quality of oversight. A 99 percent approval rate may show reliable automation, or it may show rubber stamping. Sample cases for independent review, analyse overrides by team and group, check whether reviewers had enough time, and investigate whether the model's confidence signal is calibrated. Make it easy to report a harmful or surprising result. If a reviewer cannot understand the input, challenge the output, or stop the process, describe the control honestly and redesign it.

Testing, incidents, and evidence

Testing should match the harm. Measure accuracy and error types, not only average benchmark scores. Test Portuguese language performance, accents and regional terms where relevant, accessibility, edge cases, protected or vulnerable groups, prompt injection, data leakage, retrieval errors, harmful content, model drift, and failure of connected tools. Define acceptance thresholds and a re-test trigger for a new model, prompt, dataset, integration, user group, or material vendor change.

An AI incident can be a privacy breach, fabricated advice, discriminatory outcome, unsafe recommendation, prompt injection, data poisoning, unauthorised autonomous action, misleading synthetic content, service outage, lost logs, or failed human review. Connect the response to the existing security, privacy, legal, quality, and business continuity programmes. Add model-specific evidence: version, input or retrieval reference, output, action, reviewer, affected people, reproducibility, containment, vendor escalation, and restart approval.

Preserve enough evidence to reconstruct a decision without copying sensitive prompts into a broadly accessible ticket. Set access and retention rules for prompts, outputs, logs, screenshots, reviewer notes, and affected records. The evidence file should show what was intended, what was configured, what happened, who reviewed it, what people were told, what was corrected, and why the system was restarted. This is useful for regulators and also for finding the operational bug before it becomes a legal dispute.

• Inventory record with purpose, owner, provider, version, data, users, affected people, classification, tier, and review date.
• Legal register showing binding law, guidance, standard, strategy, proposal, source, scope, and effective date.
• DPIA and AI impact review with alternatives, residual risk, approval conditions, human oversight, notices, and reassessment triggers.
• Data flow, legal basis, retention schedule, access review, transfer assessment, rights handling, deletion process, and vendor settings.
• Model and dataset documentation, evaluation methods, limitations, fairness, accessibility, language testing, and change history.
• Vendor diligence, contract clauses, subprocessors, security evidence, incident commitments, exit plan, and continuity test.
• Reviewer instructions, escalation route, training records, override samples, decision explanations, and challenge outcomes.
• Incident register, preserved evidence, impact assessment, communications, corrective actions, and controlled restart approval.
• Executive decisions, risk acceptances, exceptions, KPI reports, audit samples, and scheduled legal and governance reviews.

A practical 30, 60, and 90 day roadmap

Days 1 to 30 should create visibility and stop avoidable exposure. Name an executive sponsor, privacy lead, security contact, and use case owners. Issue an interim rule for sensitive data, unapproved tools, and high impact decisions. Inventory uses across business, IT, HR, product, security, procurement, and suppliers. Screen every use for prohibited practices, AI Act role and classification, GDPR impact, automated decision effect, sector rules, employment implications, vendor data use, and autonomous action. Assign an owner and due date to every unknown.

Days 31 to 60 should convert findings into controls. Approve the internal tiers and decision record. Create the legal register and authority map. Publish the acceptable use standard and role based training. Create an approved tool catalogue. Update procurement questionnaires and priority contracts. Complete DPIAs and AI impact reviews for the highest exposure uses. Configure access, redaction, retention, logging, notices, human escalation, incident intake, and change gates. Record future AI Act dates without treating them as current duties.

Days 61 to 90 should test the operating model. Run accuracy, robustness, fairness, privacy, security, accessibility, and Portuguese language tests suitable for each use. Sample logs and human overrides. Run an incident tabletop involving privacy, security, HR, legal, operations, and the supplier. Test rollback and vendor outage procedures. Report open high risks, overdue evidence, training coverage, material incidents, correction time, and upcoming legal dates to leadership. Set quarterly reviews and an annual reassessment of the programme.

KPIs that show control

Measure coverage and effectiveness together. Coverage measures include the percentage of known uses inventoried, the percentage with an owner and classification, completed high risk reviews, approved tool adoption, staff training by role, vendor evidence coverage, and material changes reviewed before release. Outcome measures include human review completion, meaningful override rate, error rate by relevant group and language, privacy incidents, time to contain, time to correct an affected record, rollback success, challenge resolution time, and unresolved high risks by age.

Common failure modes in Portugal

• Waiting for the later high risk AI Act dates before controlling personal data, prohibited practices, AI literacy, transparency, employment, safety, and contracts.
• Calling a Commission FAQ, CNPD opinion, national strategy, voluntary code, draft law, or future deadline binding law without checking its legal status.
• Assuming the CNPD is the only authority or that an AI Act designation automatically resolves the GDPR, sector, labour, consumer, and product safety questions.
• Treating a vendor's compliant or responsible AI statement as a risk classification, DPIA, conformity assessment, or deployment decision.
• Using consent or a disclaimer as a cure for excessive collection, incompatible purpose, weak security, discrimination, or an unfair automated outcome.
• Calling a reviewer human in the loop when that person cannot understand, challenge, override, or stop the result.
• Testing only average cases or English language performance while ignoring Portuguese use, accessibility, edge cases, and affected groups.
• Keeping unlimited prompts and outputs, copying sensitive data into tickets, or forgetting embeddings, retrieval indexes, telemetry, backups, and derived records.
• Launching a national workflow without checking employment, financial, health, safety, public procurement, consumer, and critical infrastructure requirements.
• Buying a governance platform that creates a second inventory instead of connecting to identity, procurement, privacy, security, HR, product, and incident systems.

Build versus buy

Buy commodity capabilities such as identity and access management, training delivery, ticketing, evidence storage, vendor questionnaires, logging, model access, and monitoring. Build or configure the judgement heavy parts: your Portuguese and EU legal register, authority map, use case taxonomy, risk appetite, approval gate, impact workflow, human review design, evaluation thresholds, escalation rules, and executive reporting.

A platform can organise evidence, enforce a workflow, and make a change visible. It cannot decide whether a hiring feature is discriminatory, whether a lawful basis is adequate, whether a reviewer is genuinely independent, or whether a sector specialist should stop a release. Avoid buying a dashboard that reports control while the underlying data is stale. Choose tools that integrate with the records your company already relies on, then assign people who can exercise judgement and accept responsibility.

What can we do for you?

Magna Products helps Portuguese companies turn scattered AI experiments into controlled, useful operations. We can inventory your AI systems, map EU and Portuguese obligations, distinguish binding law from guidance and proposals, design DPIA and AI impact workflows, review employment and customer journeys, strengthen vendor and procurement controls, create role based AI literacy, and connect human oversight, incidents, KPIs, and evidence to the tools your teams already use. Talk with Magna Products to schedule a focused discovery workshop and leave with a prioritised 30, 60, and 90 day implementation backlog.