Put the two safety claims side by side.
Rippling: "Rippling AI inherits your existing roles and access permissions."
HiBob: "Bob AI respects the same permission layers as the rest of Bob. It cannot access or surface any data you are not authorized to view."
Same sentence, different letterhead. Both are correct as architecture. Both are also doing the same sleight of hand: they answer the question "can the AI leak data?" by handing you the question "are your permissions right?" — which is yours, was always yours, and is the reason we run a permission audit before touching either product.
So the promise is a tie. Everything after the promise is not, and if you run one of these platforms — or you're choosing between them and AI is on the scorecard — the differences below are the ones that matter operationally.
We compared the platforms themselves in Rippling vs HiBob. This is the AI layer only.
Same promise, two different machines
Rippling AI is a query engine wearing a chat interface. Ask it a question and it doesn't summarize a pile of retrieved records — it writes SQL, or a formula, or builds a report, and executes that against live data under your permission context. Rippling's launch post is unusually direct about why: "You cannot trust LLMs to filter or redact data correctly, based on your company's permissions model – but with Rippling, you don't have to, because the LLM can only access information that the user it's chatting with can access themselves." Ask it to change something and it stages the change for human confirmation, routed through whatever approval chains you already built.
Bob Companion is a conversational layer over a family of features. One interface, routing questions to whichever of HiBob's twelve named agents — Performance, Hiring, Compensation, Payroll, and so on — can answer. Behind the agent names sit discrete module features: review-writing assistance, CV summaries, pay-equity analysis, natural-language reporting, policy Q&A grounded in company documents. HiBob has described permission enforcement at the query level rather than post-retrieval filtering, and every write action requires explicit user confirmation.
Both designs are defensible. Note what they have in common that neither markets: no public third-party security assessment has tested either enforcement claim. Both are vendor statements about their own architecture. Treat them as design intent, and verify in your own tenant — the adversarial test in our Rippling checklist works on either platform.
The scorecard
| Rippling AI | Bob Companion | |
|---|---|---|
| What you're enabling | One assistant across HR, IT, Finance; no individually named agents | One interface routing to twelve named agents, shipped as module features |
| How it answers | Generates SQL / builds the report; work is inspectable | Conversational answers; reporting, drafting, and document-grounded Q&A |
| Write actions | Staged for confirmation, then routed through existing approval chains | Drafts and recommendations; explicit user confirmation required for changes |
| The off switch | "Enable or disable AI features" — granularity not publicly documented | An AI Settings page with documented feature-level enable/disable |
| External AI clients | No publicly documented equivalent | MCP server (Claude, Cursor, VS Code, Copilot Studio) plus a Slackbot integration |
| Third-party data | Data Cloud pulls Salesforce, GitHub, Square, Greenhouse into the identity graph | Not a current product direction |
| AI standard | ISO 42001 listed among certifications | "Follows industry best practices, including… ISO42001" — alignment language, not a certificate |
| Model providers | Not disclosed on Rippling's pages; CEO has said "we've moved a lot of stuff from Anthropic to OpenAI recently" | Sub-processor list names OpenAI, Microsoft (Azure OpenAI), AWS EMEA — processing location listed as EU |
| Data residency | "US-based AWS data centres"; inference location unstated | EU processing locations listed for AI sub-processors; inference region still unstated |
| Training on your data | Product page: usage data not used to train models; terms include a license to "model" customer data — reconcile in writing | AI Terms: customer data "is not used to train artificial intelligence models" |
| AI pricing | Not clearly published; reporting on it is ambiguous | Bundled into Core; no per-seat licence or metering published |
| Status | Shipped March 2026 — "available today," with access on request at launch | Listed as a Core feature; beta-vs-GA unresolved — get it in writing |
| AI query logging | Not publicly documented | Not publicly documented |
That last row is the one to sit with. On the question that matters most for governance — who asked the AI what, and what came back — neither vendor has published an answer. Ask both.
The real difference: which direction the data moves
Strip away the feature lists and the two roadmaps are moving in opposite directions, and each direction grows your risk surface somewhere different.
Rippling is pulling the outside world in. Data Cloud, launched June 25, 2026, connects CRM records, GitHub commits, point-of-sale transactions, and ATS data into the same identity-joined graph the AI queries — matched to employee profiles automatically. It has been publicly described as able to flag inefficient AI spend and alert managers, or shut off access, when thresholds are crossed. That is a platform becoming an employee-analytics engine. The governance question stops being "what HR data can the AI see" and becomes "what can the AI infer about a person from HR data joined to their commits, their pipeline, and their expense history." Every connector you add deserves its own answer to: who can now see what they couldn't yesterday?
HiBob is pushing HR data out. The MCP server and the June 2026 Slackbot integration put Bob's answers inside Claude, Cursor, and Slack — surfaces HiBob doesn't control. HiBob's framing is fair: nothing new is exposed, approved data reaches people already authorized to see it. But the launch history is the cautionary tale. At launch, MCP authenticated as a service user — one identity, one permission group, defining everything any connected AI client could see regardless of who asked. The OAuth migration in mid-2026 fixed the model — "access is limited to that user's permissions in Bob" — but un-migrated integrations and over-scoped service users are exactly the kind of thing that survives quietly. If you're on Bob, the service-user audit comes before any MCP conversation.
Inward or outward, the consequence is identical: the blast radius is expanding beyond the module you evaluated. The vendor's permission promise covered the HRIS. It did not cover the graph.
What each vendor gives you that the other doesn't
HiBob hands you rollout control and paper. The documented feature-level AI toggle is the real thing — it's what makes a wave-by-wave rollout an actual product capability rather than a wish. The AI Terms are explicit that customer data isn't used for training and that you can switch AI off entirely through admin controls. And the sub-processor list states EU processing locations for the AI providers — more transfer detail than Rippling publishes.
Rippling hands you legibility and a certificate. The query-generation design means you can inspect what the AI actually did — the SQL is there, not a vibe. Staged actions inherit your existing approval chains rather than a parallel AI-only confirmation step. And ISO 42001 listed as a certification is a stronger artifact than alignment language; it's the one AI-governance document in this market you can actually demand and file.
What neither gives you, yet: documented AI query logging, minimum-group-size protection on aggregate questions ("average salary on a three-person team" is a name with extra steps, on either platform), a stated inference geography, or an independent red-team report. Those four go in writing to whichever vendor you run — the vendor-questions sections of our two rollout guides have the full list.
So does AI decide the platform?
If you already run one of them: no. Switching HRIS to chase an AI feature set in mid-2026 is trading a known configuration for a re-implementation, in a product category where both roadmaps are visibly six months old. The leverage isn't in switching — it's in sequencing the rollout properly and getting the unanswered questions into your contract.
If you're choosing fresh, the AI layer is a tiebreaker, not a driver — the platform comparison in Rippling vs HiBob still decides it. But as tiebreakers go: EU-heavy workforces will find HiBob's published transfer posture easier to take to a privacy review today, and operations teams that want to see the query rather than trust the summary will prefer Rippling's design. Both preferences are provisional. Both vendors will ship past this article.
People Street's take
The vendors are having a marketing war over whose AI is safer. It's the wrong war. Both safety stories reduce to the same sentence — the AI can only see what your permissions allow — which means both vendors have, politely and in fine print, made your configuration the product's security model.
That's not a criticism. It's the correct design. But it means the comparison that matters isn't Rippling versus HiBob. It's your permission model versus what a plain-English question can now do to it — and that comparison you can actually control.
Pick your platform on platform grounds. Then run the audit, stage the rollout, and get the four unanswered questions in writing. On either logo, that's the work.
If you're weighing the two — or you own one and want the AI layer stood up properly — book a 20-minute call.
Related: Implementing Rippling AI: the governance checklist · Bob Companion rollout: which agents first · Rippling vs HiBob