Most HR platforms were built as systems of record and are adding AI on top. Sparko was designed after AI changed what an HRIS could be, which meant deciding, up front, how much autonomy each kind of AI should get and what has to be true before it acts.
The more consequential the capability, the more oversight it carries. This is not a description of good intentions: it is how the product is built, and every AI feature in Sparko belongs to exactly one of these classes.
Scores, flags and signals computed from your own data. Most of this class never calls a language model at all — it is statistics you can re-derive.
Drafts, plans and summaries a person reviews and applies. The model produces an artifact; it never changes anything on its own.
Ask Sparko proposing a change to real records — and carrying it out only after a person approves that specific action.
A governance model only counts if something enforces it. These are the mechanisms, not the aspirations.
Every AI feature carries a class in the product’s own canon, and a parity test fails the build if one is missing. An AI capability cannot ship unclassified, so this page cannot quietly fall behind the product.
Class rules and plan entitlements are enforced at a single chokepoint every AI call passes through — not re-implemented per feature, where one missed check becomes a gap.
The assistant proposing an action and performing it are separate steps with separate authorization. A conversation alone can never change a record.
AI sees what the person asking already has permission to see — nothing widens access. At execution, each tool re-checks its own permission, so an employee can submit their own leave but cannot post a job.
The assistant builds its prompts from employee IDs and permission-scoped records rather than names. Résumé parsing and screening strip names, contact details and identifiers like SSNs before any prompt is sent.
Sparko never trains AI models on your data, and no customer’s data is used to improve results for another. Providers process in real time under a centrally-managed key.
Hiring is where AI in HR carries the most consequence, so it is worth being precise about what actually happens.
Screening evaluates the deterministic rules first (required skills, experience, location, work authorisation) and the model cannot overturn them. AI scoring is applied to the cases those rules alone cannot settle.
Worth being precise about what that ordering means: it is precedence, not independence. On the public careers page, the fields those rules compare (skills, years of experience, location) are extracted from the résumé by AI before any rule reads them. The rule is arithmetic; the data it reads may not be. So a parsing error can still shape a rule outcome, which is part of why the review and override controls below exist.
A model signal never rejects anyone on its own.
When the only thing against a candidate is a low AI score, screening flags them for review rather than rejecting them, and a person decides. Auto-rejection is reserved for a failed hard requirement. You still choose how much autonomy to grant: flag everything for review, auto-reject on missing required skills, or auto-reject on a failed hard requirement — but no setting lets a score alone end an application.
A recruiter can override any rejection with a reason that is recorded, and a confirmed rejection is attributed to the person who confirmed it. The public careers page carries an automated-decision notice where auto-screening is enabled, every final decision feeds the four-fifths adverse-impact audit, and candidate identity is stripped before screening runs, so the score is formed without it.
Limits are easier to verify than promises, and more useful to a buyer.
The detail a review will ask for, without having to ask.
| Use case | Class | Oversight |
|---|---|---|
| Candidate screening & ranking | Generative | Rules-first, with AI on borderline cases. Recruiters can override any AI rejection with a logged reason. An AEDT notice is shown on the public careers page where auto-screening is on. |
| Performance review drafting | Generative | Drafts cite the evidence behind them. The reviewing manager edits and owns the final text; nothing is submitted unreviewed. |
| Promotion & succession readiness | Insights | Statistical, not generated. Surfaced to calibration and succession planning as an input to a human decision. |
| Compensation & merit recommendations | Generative | Advisory only, inside budget guardrails. Every applied change writes a compensation audit entry. |
| Pay equity & adverse impact | Insights | Four-fifths rule audit across hiring, promotion and merit. Groups under 5 withheld, under 30 marked provisional. Exportable for third-party review. |
| Retention & flight-risk prediction | Insights | Statistical, never an LLM. Accuracy is graded against who actually left, so the model’s track record is visible rather than assumed. |
| Manager coaching signals | Insights | Rule-based, not generated: four concern signals and five strength signals, each quoting the number that triggered it. Praise never outranks a concern, and at most two strengths surface per run. Suggestions to a manager, never an instruction or an assessment of the employee. |
| Agentic actions on HR records | Actions | Explicit per-action approval, permission re-checked at execution, and one audit row per outcome including denials and failures. |
When a person approves an action, Sparko records the action type, its parameters, the approving user and the outcome (including denials and failures) to your security audit log, queryable and exportable by admins on every plan. The record is written independently of the action itself, so a failed change still leaves a trace. See the Security page for the wider audit model.
Insights and Generative run on Sparko’s own centrally-managed provider key. Two channels instead send data to a destination you control, both available from Growth upward, and both read-only.
Hosted MCP server. Connect Claude Desktop or another MCP client and it acts as the signed-in employee, under live per-user RBAC, through seven read-only tools filtered by that person’s permissions and your enabled modules. Per-user OAuth 2.1 with PKCE and browser consent, rate-limited per tenant, and it follows your workspace AI switch. It writes its own audit trail.
Read-only Integration API and webhooks. Tenant-scoped API keys (hashed, shown once), narrow scopes, PII-omitting projections, rate limits. Outbound webhooks are HMAC-signed with SSRF-guarded targets.
Neither channel can change anything, and neither widens access: a client reads only what that user could already read in Sparko.
EU AI Act. Employment and worker-management AI (anything that screens, ranks, scores or selects candidates) is classified high-risk under Annex III. Those obligations moved from 2 August 2026 to 2 December 2027 under the Digital Omnibus on AI (Regulation (EU) 2026/1744), which entered into force on 27 July 2026. They point at risk management, data quality, logging, documentation, human oversight and accuracy, which is why the class model above exists now rather than closer to the date.
UAE PDPL. Federal Decree-Law No. 45 of 2021 gives individuals the right not to be subject to a decision based solely on automated processing, including profiling, where it produces legal effects or similarly significantly affects them, the same boundary the human-review controls above are drawn around.
NYC Local Law 144. The bias-audit obligation sits with the employer, not the vendor, and requires an independent auditor annually. Sparko’s built-in four-fifths analysis is not that audit: it is the export that feeds one, alongside the automated-decision notice and the logged human override the law contemplates.
This describes the regulatory landscape and how Sparko is designed against it. It is not a claim of certification, nor a compliance opinion for your organisation.
Every AI capability in Sparko is listed with its class and the plans it is available on, in the feature matrix on our Pricing page. That matrix is the register: it is maintained alongside the product rather than restated here, so the two cannot drift apart.
We’re happy to walk your security, privacy or AI governance team through any of this in detail, including the parts still in progress.