EU AI Act Compliance

Collty supports strategy, domains, business processes, projects, teams, shared knowledge and connected applications. Business Architect helps develop the company's process architecture; Project Architect helps turn a brief into phases, epics, sprint-sized tasks and dependencies. Agents help people work with that structure and carry out configured project and process workflows.

The current team workflow concerns existing internal teams. AI helps a manager see relevant roles, competencies and experience in those teams; it does not independently select people, grant access to work or make assignments. Recommendations are optional: the manager can browse and choose any team available under their existing permissions, including teams outside the suggestions. AI relevance does not change those permissions. The manager chooses the team and decides how the work is allocated. This intended use is distinct from automated recruitment or personnel decisions, and does not automatically make the workflow high risk. Other retained recommendation or allocation mechanisms require their own purpose-specific review.

Collty assesses its role as provider of its own AI systems and the customer's role as deployer where applicable. Using an external model does not transfer responsibility for Collty's product purpose, evidence selection, permissions or action controls to that supplier. The Act can apply to systems offered in the EU and to relevant outputs used in the EU, even when a provider is established elsewhere.

The following distinguishes engineering controls present in the product from legal conclusions and operational evidence that require separate verification. A database record, passing test or published policy is not by itself proof that every applicable obligation has been fulfilled.

Collty is not designed, offered or permitted for AI practices prohibited by the EU AI Act. Collty does not provide biometric identification or categorisation, facial-image scraping, emotion recognition, social scoring or criminal-risk prediction capabilities.

• Do not use Collty to manipulate or deceive a person, exploit age, disability or social or economic vulnerability, or materially impair a person's ability to make an informed decision in a way likely to cause significant harm.
• Do not use Collty to create social scores or to make unrelated detrimental decisions based on inferred personality, social behaviour or protected characteristics.
• Do not use Collty to infer race, political opinions, trade-union membership, religious or philosophical beliefs, sex life or sexual orientation from biometric or behavioural data.
• Do not use Collty or connected AI tools to generate non-consensual sexual imagery or child sexual abuse material.
• Do not repurpose professional recommendations as automatic employment, dismissal, worker-management, credit, insurance, education, law-enforcement, migration or public-benefit decisions.
• Do not bypass human review, profile inspection, permission boundaries or recorded approval controls where a decision can materially affect a person.

Actual use and reasonably foreseeable misuse remain part of each system's documented risk review. Collty may restrict, suspend or investigate use outside these product boundaries.

Collty tracks the application dates published by the European Commission and records the applicable date in each system assessment. The current timeline reflects the AI Omnibus that entered into force in July 2026 and may be updated if the legal framework changes.

A date in this table does not classify every Collty feature into that category. Classification and resulting obligations are assessed per system, intended purpose, deployment context and foreseeable use.

The protected versioned inventory records the intended purpose, owner, provider and deployer role assessment, model categories, input and output categories, people affected, human-oversight requirement, Article 50 transparency requirement, risk class, assessment state and review date for each system.

Recommending relevant teams from roles, competencies and experience is not prohibited in itself. A high-risk classification means additional requirements, not a ban on that function. Classification follows the purpose and effects of the workflow, not the cabinet name, subscription or presence of an AI label. Ordinary task storage, invoices, calendars and permission rules are not automatically AI systems; an AI feature inside a project-management tool can fall within Annex III when its intended use meets that category. Recorded classifications change only through a versioned assessment with documented rationale.

Factual role evidence

The specialist inspector presents role evidence instead of an overall individual score or numerical ratings for expertise, delivery or team fit. Listed capabilities, linked cases, reported availability, confirmed allocation hours and recorded shared work are shown with their source categories. Presence of a capability or case does not verify proficiency. Missing records do not imply low ability or poor performance.

• Profile declarations and shared competency or industry labels are distinguished from project and work-relation records. Shared context does not predict personality, compatibility or future performance.
• Confirmed hours and pending invitation hours are shown separately. Utilization is the ratio of confirmed hours to stated capacity, not a score for a person; incomplete data is marked as unavailable.
• The manager inspects the evidence, confirms relevance and availability with the specialist, edits the composition and makes the assignment decision. The factual evidence summary does not select, exclude or change anyone’s access or assignments.
• Specialists can correct their professional profile and request review of inaccurate AI interpretations through the existing profile AI-matching controls.
• Team intelligence retains heuristic indicators for the team’s composition, role coverage, availability and recorded collaboration context. They are not validated measurements of individual ability or a guarantee of delivery. Limited evidence, historical assumptions and outdated data must be considered when interpreting them.

Optional work interests · RIASEC

A specialist can optionally complete the O*NET Mini Interest Profiler: 30 activities covering six RIASEC work-interest directions. It is a self-report questionnaire with deterministic scoring, not an AI inference about a person. The six independent 0–20 results describe interests; they do not measure competence, personality, suitability or performance. Existing competencies, services, tools and cases remain separate.

• Results are private by default. The individual controls sharing, withdrawal, retaking, export and deletion. Declining to complete or share the questionnaire is not treated as a deficit.
• Shared results appear separately in specialist details and Team intelligence. Individual answers remain private and encrypted; sharing reveals the six results and completion date under existing profile visibility permissions.
• RIASEC answers and results are excluded from AI prompts, vector retrieval, ranking, matching, task allocation, team-quality indicators and outcome learning. They are not used for hiring, contracting or other personnel selection.
• Collty reproduces the original English instrument and scoring with attribution and licensing information. Its presentation does not claim independent psychometric validation or endorsement by the US Department of Labor.

Voluntary project feedback

Project pulse is voluntary, manually reported feedback about the project, not biometric emotion recognition or a diagnosis. It is separate from task status, team composition indicators and specialist assessment. One latest response per participant is included for 30 days, with an aggregate shown only after three responses. Before submission, the interface explains that saving a rating of 1, 2 or 3 automatically sends the reported reasons and optional details in a private message to an authorized project manager. Reasons and details are not included in the shared aggregate. Specialists are invited to check in once per sprint and may dismiss the invitation. New responses are not used for individual or team ratings, profile signals or quality badges. Historical records are retained under the existing data-rights process; historical derived models require separate review.

Removing individual scores, aggregating outputs or retaining a human decision does not by itself exempt an AI system from Annex III. Recommendations used for recruitment, covered task allocation or worker monitoring require an assessment of purpose and actual use, including self-employment contexts. An Annex III system that profiles people is always high risk under Article 6. Any claimed Article 6(3) exception needs its own documented assessment and applicable registration; Collty does not claim such an exception or completed conformity assessment here.

Collty agents are created to assist people and work with projects, processes and teams. Their role, context and executable route are configured in Agent Center. A model's suggestion or statement that an action is complete is not execution evidence: the server resolves the operation, checks authority and records the result.

• Company owners and authorized team managers control agent use and creation rights, the number of personal agents and personal AI allowances. A specialist cannot grant themselves management access or increase their own allowance.
• Server checks resolve the company, project, team, actor and connected resource. Company membership or access to a chat does not itself authorize every record, financial operation or external service.
• MCP tools operate through authorized connections and supported capabilities. A connection does not give an agent unrestricted access to all servers, databases or applications; the permitted operation and resource scope still apply.
• Configured, explicitly preauthorized internal actions can run automatically. Actions outside that authorization or subject to a required approval gate need the appropriate approval. Human oversight does not mean asking again for every already-authorized routine step.
• Execution records, validation, retry and deduplication controls help distinguish a prepared output from an actual change. Changes to action authority, connected tools or purpose trigger a new risk and configuration review.
• A customer's custom agent remains subject to its actual use and effects. Using a business-workflow label does not permit prohibited practices or bypass separately governed people-affecting functions.

• Inputs depend on the workflow: authorized business and process records, project briefs, tasks, files and connected resources, or permitted professional experience and competency evidence. Only data relevant to the requested purpose should enter model context.
• Private context is minimized, structurally filtered and permission-scoped before an external model call.
• Protected characteristics are excluded from the intended recommendation contract. Proxy discrimination, missing evidence and unsupported inferences remain risks to test and monitor; exclusion from a schema alone does not prove absence of bias.
• Vector retrieval finds relevant evidence; domain validation checks coverage, availability, recorded work context and constraints. Retrieval does not establish that a profile declaration is verified proficiency.
• Models interpret and synthesize bounded evidence. They do not receive unrestricted database access or authority to invent people, roles or evidence.
• Evidence IDs and provenance connect an output to the records and algorithm version that supported it.
• Governance narratives, review evidence and questionnaire answers use protected server routes and encrypted storage. Data minimization, retention, correction, export and deletion remain governed by the Privacy Policy and applicable data-protection law.
• Private workspace content is not used to train public or shared foundation models. Supplier processing terms, retention and transfer safeguards require their own verification; internal recommendation calibration is separate from foundation-model training.

Collty uses versioned private evaluation datasets and task-specific graders. Team Assembly evaluation checks recommendation relevance, mandatory capability coverage, unsupported inclusion or exclusion, invented roles or evidence, allocation constraints, stability and recorded outcomes. These checks evaluate system output, not a specialist's personal worth or verified proficiency. Remaining outcome-based recommendation models require their own bias and classification review.

Project Architect evaluation measures phase and task completeness, dependency validity, realistic duration, sprint consistency, role and assignee correctness, absence of invented professionals and commercial consistency.

• Expert-authored golden references are separated from captured production output.
• A fixed baseline and holdout comparison are retained for candidate ranking calibration.
• Signals use a versioned normalization contract, recency weighting and recorded source type.
• Calibration candidates remain shadow-only until minimum evidence and quality gates are met.
• Canary exposure and outcome coverage are measured before promotion.
• Promotion requires human approval; a previous verified version remains available for rollback.
• Selection bias, confounding and causal-attribution limitations are documented instead of being hidden by a single aggregate score.

• AI tools and agent interfaces identify their AI-assisted purpose. Coverage, clarity and accessibility of notices must be checked at first interaction across supported interfaces.
• A user can inspect the real professional profiles, roles and available evidence included in a team option.
• The team picker separates My teams from AI suggestions. Recommendations do not remove access to other authorized teams; the manager can choose a team without following the AI suggestion.
• The authorized user chooses teams, approves project activation, decides personnel assignments and controls access. Configured routine agent actions may then run within the granted authority.
• Material agent actions follow configured approval and permission boundaries and are recorded with the resulting change.
• Collty can explain the principal professional evidence supporting an included recommendation without exposing hidden candidate pools, another person's private data or proprietary ranking weights.

A professional can update or delete their profile, change visibility and report inaccurate or unsupported evidence associated with their own account. This correction mechanism addresses data and system error; it does not make Collty the adjudicator of an independent customer's final team choice.

Article 50 separates user-facing disclosure from technical output marking. Covered AI interactions require clear, accessible notice at first interaction unless AI involvement is already obvious in context.

• Providers of systems generating synthetic text, images, audio or video must support machine-readable marking and detectability as technically feasible. Standard editing and assistance that does not substantially change the input or its meaning have specific exceptions.
• Deployers must disclose generated or manipulated deepfakes. AI-generated text published to inform the public on matters of public interest also requires disclosure, subject to the human-review or editorial-control exception when a person or entity holds editorial responsibility.
• The editorial exception for public-interest text does not automatically remove provider output-marking duties or the separate deepfake disclosure requirement.

The versioned risk register covers discrimination, ranking and selection bias, erroneous exclusion, hallucinated evidence, private-data leakage, prompt injection, model or provider failure, over-reliance, drift, unauthorized actions, weak evidence and misuse outside intended scope.

• Capability and evidence validation before a person is included in a recommended team.
• Grounded IDs and schema validation for model output.
• No invented professional profiles or unverified team members.
• Low-evidence states that preserve uncertainty instead of forcing a fabricated recommendation.
• Provider timeouts, retries, deduplication and deterministic fallbacks that preserve verified evidence.
• Token, latency, error, quality and drift accounting by task and provider.
• Durable outbox processing for evidence and provenance events.
• Shadow provider comparison, canary activation and rollback controls.

Production monitoring records quality, pass rate, latency, provider errors, timeouts, token cost, drift, duplicate calls, eval coverage, calibration exposure and observed outcomes. Reports of incorrect evidence, unexpected exclusion, unsafe recommendations or unauthorized action can be recorded against the applicable AI-system version.

• Incident severity, affected people, source and protected narrative.
• Serious-incident candidate status and lifecycle state.
• Containment, corrective action and final resolution.
• Linked system version, evidence and audit events.
• Review of whether rollback, suspension, notification or model/provider change is required.

Collty's technical file is assembled from versioned system inventory, intended-purpose records, data-flow and privacy controls, risk assessments, DPIAs, evaluation datasets and graders, model/provider configuration, provenance, monitoring, incidents, literacy records, release evidence and change history.

The operating quality system separates build, validation, shadow evaluation, human approval, canary activation, monitoring and rollback. A code deployment alone does not silently promote new ranking weights.

For a system assessed as high risk, the applicable programme must cover risk management, data governance, technical documentation, logs, deployer instructions, effective human oversight, accuracy, robustness and cybersecurity, together with provider and post-market obligations. The required conformity route, EU declaration, CE marking, registration and an EU authorized representative where applicable must be established for that system. Annex III categories 2–8 generally use the internal-control route under Annex VI; this is not a blanket requirement for an external certification body. Collty does not claim these formal steps have been completed by publishing this page.

A company configures its processes, teams, agent authority, connected resources and access boundaries. It remains responsible for the relevance and lawful use of its inputs, the decisions it makes and the way it deploys AI in its workplace. A subscription does not replace these responsibilities.

• Use systems within the documented purpose and instructions. Give oversight to people with the competence, training, support and authority to review, override or stop the relevant operation.
• Check evidence and generated plans before consequential use. Keep permissions and connected resources current, and report incorrect evidence, unsafe outputs or unauthorized actions.
• Where high-risk workplace rules apply, inform affected workers and their representatives, monitor use, retain the required logs under the applicable retention rules and meet incident-reporting duties.
• Assess GDPR obligations, including any required data-protection impact assessment. An Article 27 fundamental-rights impact assessment has a specific deployer scope; it is not automatically required from every private company using a project tool.
• Changing a system's purpose, substantially modifying it or rebranding a high-risk system can change the customer's provider responsibilities under Article 25. Review these changes before putting the modified system into use.

Collty integrates external model, embedding and connected-service providers. Supplying an application that uses a general-purpose model is distinct from placing that model itself on the market. Supplier documentation, capabilities, limitations, processing terms and changes are part of the integration assessment; the supplier's own compliance statement does not certify Collty's application.

General-purpose model providers have their own Chapter V obligations, including documentation for downstream integrators and applicable copyright and training-content transparency duties. If Collty's role changes through model development, modification or distribution, the corresponding provider obligations must be reassessed. MCP service access also remains subject to the connected provider's permissions, contractual terms and data safeguards.

Collty's programme defines role-specific modules for administrators, product owners, engineers, support staff and deployer-facing roles. A protected register supports programme version, module, role scope, assignment, completion, expiry and evidence. At the 2 October 2026 review, it contained no completion records; a defined programme is not represented as completed training.

Article 4 calls for measures supporting AI literacy with regard to people's knowledge, experience, role, use context and affected groups. The programme and register support those measures; they do not prove that training has occurred or guarantee a particular level of literacy for every individual. Actual participation and completion evidence remain operational verification items.

• Responsible operation and intended-use boundaries.
• Human oversight and review of generated output.
• Data governance, privacy and security.
• Bias, uncertainty and evidence quality.
• Incident identification, escalation and corrective action.

Collty has implemented the product boundaries and technical infrastructure described here. The remaining assessment covers people-affecting recommendation and allocation models, historical derived records, generated-content marking, notice coverage, actual training evidence, supplier documentation and the completeness of system-specific legal and operational records. Neither removing visible personal scores nor giving a manager the final decision closes that assessment.

Correction, review and complaints

Users can correct their own profile and use the protected AI-matching review workflow to report inaccurate or unsupported evidence. Privacy, access and deletion requests can be sent to privacy@collty.com. Include the affected feature, project or output reference and a description of the concern; never send passwords or connection secrets. Collty can investigate its data and system behaviour. The company making a consequential decision remains responsible for explaining that decision.

Where Article 86 applies, an affected person may request a meaningful explanation from the deployer of AI's role in a qualifying adverse decision based on a covered high-risk system. Reporting a concern to Collty does not remove the right to complain to a competent market-surveillance authority under Article 85, or applicable data-protection and judicial remedies.

Official references

• European Commission: AI Act framework and application dates
• Article 2: territorial and material scope
• Article 5: prohibited AI practices
• Article 6: classification and documented exceptions
• Annex III: high-risk use categories
• Article 50: interaction notices and generated-content transparency
• Article 4: AI literacy
• Article 26: deployer responsibilities
• Article 25: responsibilities when a system is changed or rebranded
• Article 27: fundamental-rights impact assessment scope
• Article 43: conformity assessment routes
• Article 53: general-purpose model provider obligations
• Article 85: complaints to market-surveillance authorities
• Article 86: explanation of qualifying individual decisions
• O*NET: Interest Profiler purpose and scientific documentation
• O*NET: proper use, including the restriction on employment selection