An algorithm doesn't get a different set of rules than the property manager reading the application by hand. It gets the same rules, applied to a process that's now faster to run and harder to explain after the fact.
Key takeaways
A property management company that runs applications through a scoring tool hasn't created a new category of decision. It's automated an old one, and the old one already has a regulator's rulebook attached — one written for a human reading a file, that doesn't relax because the reader is now software.
The Ontario Human Rights Commission's policy on human rights and rental housing draws tenant-selection rules directly from Regulation 290/98 under the Human Rights Code, and states them narrowly: “Rental history, credit references and/or credit checks may be requested. A lack of rental or credit history should not be viewed negatively.” The Commission adds that “a landlord can ask for income information, but they must also ask for and consider together any available information on rental history, credit references and credit checks” and that “income information can only be considered on its own when no other information is made available”. Crucially: “Regulation 290/98 under the Code permits no other inquiries”
That last line is the one an automated system trips over easily. A scoring model built to be “thorough” tends to pull in whatever fields are available — social media presence, employment-sector risk, a general credit-bureau risk score built for lending rather than tenancy — and every field beyond rental history, credit references/checks and income is a field the regulation doesn't permit asking about in the first place, regardless of who or what is doing the asking.
Two OHRC rules are the ones a scoring tool is most likely to violate silently. First: “A lack of rental or credit history should not be viewed negatively.” A model trained or tuned to prefer applicants with an established credit file will do exactly what that rule prohibits unless someone has explicitly excluded “no history” from counting against a score. Second, and more bluntly: “It is illegal for housing providers to apply a rent-to-income ratio such as a 30% cut-off rule” A tool that flags or auto-rejects any application where rent exceeds a fixed share of stated income is applying precisely the rule the Commission calls out by name — the fact that a spreadsheet formula or a model threshold did the flagging instead of a person doesn't change what the rule prohibits.
The exception is narrow: the 30%-style ratio is permitted only for applications to subsidised, rent-geared-to-income units — not as a general screening shortcut for market-rent applicants.
Québec's Law 25 adds a distinct obligation that applies wherever a decision about a person is based exclusively on automated processing of their personal information. Québec's access-to-information regulator, the Commission d'accès à l'information (CAI), states the rule this way: “Les organisations doivent notamment informer la personne concernée lorsqu'elle fait l'objet d'une décision fondée exclusivement sur un traitement automatisé de ses renseignements personnels … Les organisations doivent également donner l'occasion à la personne concernée de présenter ses observations à un membre de leur personnel en mesure de réviser cette décision.” (Québec French-language original.) In plain terms: if an applicant is screened, scored and rejected without a person ever looking at the file, the operator must tell the applicant that's what happened — no later than when it tells them the outcome — and must give them a real chance to have a staff member review the decision.
The same CAI page adds a second, separate obligation for any technology that identifies, locates or profiles an applicant: the organisation must tell them beforehand that the technology is in use and how to activate or deactivate its functions, and profiling functions must be “off by default” (“ces technologies ne pourront être activées par défaut”) That reaches a scoring tool that builds a behavioural or risk profile from an application, not just one that issues a final accept/reject.
This is a provincial rule, not a national one — nothing in Ontario's OHRC framework requires the same disclosure-plus-review-right mechanic. Track them separately by province rather than writing one “Canadian rule.”
PIPEDA sets the general federal test for why any of this data can be collected at all: “An organization may collect, use or disclose personal information only for purposes that a reasonable person would consider are appropriate in the circumstances.” (PIPEDA s.5(3)) That's the statutory hook behind “only ask what the regulation permits” — a scoring tool that pulls extra data fields because a vendor bundled them in is collecting for a purpose the applicant never agreed was appropriate, on top of whatever provincial tenancy or human-rights rule it may also be breaking.
The privacy commissioners' joint generative-AI principles add a fairness test worth applying to any scoring model, not only ones marketed as “AI”: developers and users should evaluate training data “to ensure that they do not replicate, entrench, or amplify historical or present biases” and avoid deploying systems that fall into what the principles call “no-go zones” — “profiling that may lead to unfair, unethical, or discriminatory treatment”. A rejection pattern that correlates with a protected ground named in the Human Rights Code — family status, disability, receipt of public assistance, and the rest — is exactly the outcome that test is aimed at catching before it becomes a pattern of complaints.
Draft vs decide
A tool may: pull a credit report, verify stated income and employment, flag missing documents, and rank completed applications for a human reviewer's queue.
Only a person decides: which applicant gets the unit, how the OHRC's “consider together” rule applies to a specific mixed file, and any override where the score conflicts with information the applicant has provided directly.
A property management company operating 40 units in Ontario licenses a screening tool that pulls a credit-bureau score, checks rental history against a tenant database, and produces a 1–100 “risk score” with a recommended accept/decline. Out of the box, the vendor's default configuration treats “no credit file found” as a moderate risk penalty — a common default because lenders use it that way — and the tool has no income field at all, so the property manager's staff have been entering income separately and applying their own informal 35%-of-income cutoff before a file even reaches the tool.
Both defaults are OHRC problems, not just tool-configuration quirks: penalizing “no credit file” directly contradicts the Commission's rule that a lack of history “should not be viewed negatively”, and a 35% income cutoff is exactly the kind of ratio rule the Commission names as illegal outside rent-geared-to-income housing. The fix isn't more automation — it's two configuration changes and one process change: the vendor disables the no-history penalty at the property manager's request, income is entered into the tool alongside rental history and credit references so all three are “considered together” as the regulation requires, and the income-ratio field is removed from the workflow entirely rather than reworded. A named staff member reviews every decline before a rejection goes out, which satisfies Ontario practice and would also satisfy Québec's automated-decision notice-and-review rule if the same company operated there.
None of that required turning the tool off. It required treating the tool's defaults as a policy decision the property manager is responsible for, not a setting the vendor already got right — the same discipline the privacy side of tenant data and vetting a vendor before the contract is signed cover for the underlying data question.
No — using a tool isn't itself the problem. The problem is a tool configured to ask about or weigh factors Ontario's Regulation 290/98 doesn't permit, or one that makes a final decision without the notice-and-review mechanism Québec's Law 25 requires where a decision is based exclusively on automated processing. Configure the tool to the same rules that already apply to a person doing the same job.
Only if that click reflects a real review, not a rubber stamp. The CAI's guidance requires that the person be told a decision was automated, no later than being told the outcome, and be given a genuine opportunity to have staff review it — a workflow where staff never see declined files until an applicant complains doesn't meet that standard.
Yes. The OHRC policy expressly permits requesting rental history, credit references and credit checks — the risk is in going beyond those three categories, in treating a thin credit file as a negative, and in applying an income ratio outside subsidised housing, not in checking credit itself.
A 30-minute call is enough to tell you whether AI pays for itself here.
