Just another scheme to abstract away responsibility for systemic biases/oppression. Now you don’t even have to take responsibility for your (potentially small) part in the end result, because you can just blame it on the computer!

Whatever happened to this 1979 IBM presentation?

I take it to mean that the people pushing requirements for a program/system, the people implementing it, and the people utilizing it all hold a certain measure of responsibility for what is done with it.

My “most dangerous” creation is automation for certain employee onboarding and separation tasks, relating to their network sign in account and email. It is entirely triggered by data from our HR/payroll system, making the HR and each person’s manager responsible for the input and results.

The only part that “makes decisions” that might differ from the input is the “sanitizing” of names for email address generation. I use a .Net library built into Windows to “normalize” accented characters like ö.

I’m comfortable leaning on Microsoft’s “normalization” procedure. Better than rolling my own for an edge case that is rare at my workplace. End-users can assign their own “preferred name” in the HR system, and HR can modify the “legal name” values as needed. Lastly, anyone can request their email address to be changed to just about whatever they want at our helpdesk’s discretion.

Employee separation processing happens at end of day, with a manual process that HR can kick off for “high risk” ones that must be immediate (like security escorted someone out). There is a metric shit ton of planning put into the aging off of different parts of the employee data, with considerations for short contract renewal gaps, ability to pull critical data from separated accounts within a reasonable timeframe (and with appropriate approvals), and various legal requirements we’re beholden to.

Fun fact for separation calls through Teams from HR to remote workers: a user who has been disabled in AD and Entra, who has had their Azure/Entra/365 access tokens revoked, and whose password has been changed… can continue an active video/voice call in teams that started before they were “locked out”. They can’t access or create any other text chats, file sharing, or even the text chat for the existing call though. Makes it easy for HR to have access removed during the call. The user will still have access to any local content on their machine for as long as they stay logged in, but it’s at least something (especially combined with a default block on USB storage to help prevent data exfiltration). Please test yourself before relying on this though, as Microsoft changes shit with Azure daily.

Anyway… the point is, this is shit I thought out, along with a ton of other considerations. I know for certain how my code reacts to things, and I am comfortable with all the potential outcomes even when things go wrong.

When shit goes wrong with it, I openly and clearly point out where it’s an issue with input data from HR. When it is a problem with the code, I openly and clearly take responsibility as I wrote the code. I never go “it’s the computer’s fault”. Even if it is some problem with Microsoft’s code I hook into, it is my fault for not fully understanding what I told the code to do.

I truly have a hard time comprehending just how comfortable all these people are with the black box nature of AI, especially for such important things like fucking tenant screening.