I'm with Dave on this one, but I'll say it another way.
Don't invent a new solution when an existing one will work. Training is a process just like any other. You have inputs (the trainer, the trainee, and the training materials) you have process steps (the presentation) and you have outputs (the trainee with modified behavior).
If you have an assembly process and you need to know that a particular screw was installed in every unit, you wouldn't record that the unit went through the "screw installation work-cell" right? You would want evidence of the installed screw! Same with training. You design the training materials and presentation, you validate that the training process itself is effective if applied as designed, and then you verify that an employee was trained with a validated test for the characteristic that was added in the process, i.e. the desired behavior.
Now your training records are objective evidence of the desired behavior, not that the trainee went through the training. Maybe an actual administered test, maybe a process metric they are responsible for. Yes, designing tests is a job in itself, and the test itself has to validated, but in QA don't you constantly design and validate tests already? Same thing.
Do this, and then if you have to refer back to the training records (why else would you keep them?) you have objective evidence that the employee had the required knowledge because they exhibited the behavior as desired. The record is then authenticated by the person doing the verification test, not a list of illegible employee signatures, and you can stand up in court (if it comes to that) and say "Here is proof that employee X knew Y, and therefore had been trained." How do you know the test applied verifies what you claim? Provide evidence of the original validation of the test itself, or better yet re-run the validation of the test.
Incidentally, the above also gives you a water tight alternative to "grandfathering" employees WRT training requirements.